View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006917 | ardour | features | public | 2016-07-06 06:11 | 2016-07-06 22:07 |
| Reporter | BigstevE | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Platform | GNU/Linux | OS | Slackware | OS Version | 13.37 , 14.1 |
| Product Version | 5.0-pre | ||||
| Summary | 0006917: Improve Ardour's keyboard functionality by incorporating input-focus, additional keycommands and resolution control. | ||||
| Description | Here are some thoughts on how increasing Ardour's keyboard control functionality can help to enhance it's overall workflow. Windows (and Linux programs with redmond-like UI's) makes good use of the F6 key (arbitrarily speaking.. it could be *any* key) to switch input focus to different areas of the UI. This could prove useful for example, when switching between the processor-modules section and mixer (meaning pan, fader, input trim and M-S-R-iso buttons). Or switching input focus from anywhere within the editor-mixer's controls to the transport; Or to the waveforms in the editor canvas. It could save from having to point, drag, aim and click repeatedly just to make use of one's own devised keybinding (especially now with multiple bindings subsections in ardour.keys). Moreover, it could actually help in preventing unwanted key-conflict among areas (i.e. accidently starting the transport when trying to toggle a channel's processor modules). Having a mapped key, or <modifier>+key combination to move/switch input focus among/between input-regions can benefit *all* elements. Not just pan, fader, etc. Additionally, there can, and should be, more keybinding commands made available for keyboard-based control. This would benefit all users like myself who either are afficted with, or are trying to avoid, carpal mouse syndrome; As well as those who aren't endowed with a most ideally customized and functioning MIDI controller (do these even exist?) while doing mixdowns and edits from their keyboard. Basically for all post tracking work. I'm postulating here but it seems to me if fully developed, this level of control could encompass all the available parameters a plugin's GUI has (buttons, sliders and knobs) if controlled via the mixer channel's processor modules section. Which would seemingly require such refinements as enabling the re-ordering of a plugin's inline processor controls (the order in which they are displayed, not just what controls one chooses to display), and changing switch controls to show as OFF/ON instead of a redundant fader values that only 'actuate' at a specific value*. It may be how the values works for MIDI controls and the like but there are better ways to show/interface with it on screen in such cases. Also, some plug-in's buttons are ideally controlled differently from the typical 'Bypass' switch manner (one example being Harrison's GVerb+ which has audition switches for Wet/Dry values). A user may wish to declare this kind of switch to behave as momentary in the inline processor controls if it doesn't already do so. I guess having the ability to rename some parameter values to more human-readable tags wouldn't hurt either. * This may have been addressed by rgareus in commit ff50b37 from July 4th in the git repository. These aren't feature requests for more effective keyboard use for keyboarding's sake. Though all users can use the "focus follows mouse" feature to go "clickless" when switching to and from input-regions, mouse movement is still necessary at all times, with the sole exception being switching between the editor and mixer. This has detrimental effects to even the most mouse-centric user if they have to be constantly averted from executing meticulous selections and waveform edits with the mouse; Every time in mid-edit (or between edits) something needs to be changed in an area with a different input-focus this mouse-driven process has to be done over. And over. I prefer a minimized and efficient use of the mouse and find it most useful for doing specific waveform edits and selections, not (constantly) moving around between elements to select focus. My ideal workflow within Ardour would utilize constrained mouse movement with the <Ctrl> modifier and other such things that Windows and synaptics drivers support. Similarly, Windows has MouseKeys which allows configurable control of IF, HOW, and HOW MUCH the mouse pointer speed changes. IF (at all), HOW (momentarily toggled on/off with a modifier key or by timed ramping of speed depending on how long the arrow keys are pressed), and HOW MUCH (max or min speed, and the timed rate of (de-)acceleration). With it's presumed keyboard.bindings support for mixer elements like pan, fade etc. the part of MouseKeys-like functionality that could become integral to Ardour are the (de-)acceleration speed of parameter controls while modifier and movement keys are held. No actual mouse movement emulation being necessary. It could stay in one spot for edits and still take advantage of the "focus follows mouse" model when focus is released/changed from an other area. Looked into further, the use-case benefits of having speed controls for keyboard-controlled parameters like fader, pan, input-trim (or any plug-in's knob or slider parameter whatsoever) correlate closely with their having support for fine, and extra-fine mode resolutions as well. Ardour currently has mouse support for fine-resolution parameter control with the <Ctrl> and <Alt> modifiers and (currently broken) support for overriding a mix group assignment for the fader and mute with the <Alt> modifier. There's no reason this can't apply to keyboards. As well as MIDI faders. | ||||
| Tags | No tags attached. | ||||
|
|
Please Note: What follows below is much more hypothetical and assumes things I don't really know the inner workings of. It postulates more details of how such an underlying framework for enhanced keyboard integration would work in theory, not in code. There's usually not much point in proposing examples for the keybindings files since everyone's ideal use would be different. Also, having multiple .bindings regions essentially constitutes multiple keymodes, and the potential drawbacks they bring. While the current iteration of ardour.keys has different subsections for Global, Editor, Mixer, Step Editing, Monitor Section and Processor Box, there doesn't appear to be support for two identical keybindings within the same active window, but can apply to different subsections based on context. So I'll identify the keybindings currently as having a pseudo-nested layout. Yet the manner in which I envision most new keycommands functioning within the ardour.keys Global-Local structure would be having them operate in a truly nested context. Specifically, those keycommands whose context depends on specific input-focus areas. Such entries are conceived in co-ordinance with the particular input-focus areas they reside, thus determining what bindings.file subsection they'd belong. So, I'll give some examples to demonstrate how some newer keyboard actions might work in the context of current .bindings files. For example, having two different actions bound to the "KP_0" key in the mixer window. One applicable to the mixer.bindings and one specific to processor-box.bindings. If, say the mixer screen is active yet nothing is in a discrete keyboard input-focus, then a given command like "KP_0" would default from it's context-sensitive state --> processor-box.bindings to it's sub-section parent function specified elsewhere in --> mixer.bindings: <Binding key="[0-9]" action="Enter-processor-controls-value"/> would revert to <Binding key="0" action="Mixer/unity-gain"/> # mixer.bindings specific An input-focus hotkey to move or toggle input focus among these different areas would have to serve as a branch between ardour.keys (and it's subcategorical bindings) and context-dependent fully-nested sub-layer.bindings (which could belong to any of the aforemented ardour.keys sections as a child function). /* This part probably makes make no sense */ As an intermediary between the two the input-focus hotkey (say F6) should, itself, have the ability to be mapped to an alternate command in at least one of the relevant sub bindings; If only in principle. Not that it should be, of course but if it was unchangeable thoughout that would make it global, and global keys don't have any definition of context. Here, a specific 'escape' key sequence particular to the Step Editing mode would perhaps revert the context-sensitive input-focus keybinding back to "F6" of it's being locked into <Binding key="F6" action="StepEditing/note-length-sixteenth"/>. So presumably, if there has to be a duplicate key entry to the input-focus hotkey anyplace perhaps some definition in the editor screen that is menu-specific, and only engages as a shortcut to a menu sub-entry when the menu (F10-a global) is active would be most ideal. (I know this is getting ridiculous if it implies there being a menu.bindigs file!) /* I told you so */ As a sort of Alt-Tab for a screen's section of internal elements, input-focus switching would be most functional if it adopted it's paternal WM's context-aware focus behaviour. Meaning (F6) would cycle, in directional order, the mixer or editor's different elements while <Shift>F6 would do the same in reverse. An additonial modifier, <Ctl>? when held during cycling, would remember the previously active input-focus region, while yet another <Alt>? could switch back and forth between the current and last active input-focus region. This seems like a clusterfudge but consider that the actions of a well designed keybindings file would automatically apply focus and appropriate context to the relevant region/elements of the mixer, lets say. <Bindings name="ardour-mixer"> <Press> <Binding key="Secondary-s" action="Mixer/solo"/> <Binding key="Secondary-m" action="Mixer/mute"/> <Binding key="Secondary-i" action="Mixer/toggle-midi-input-active"/> <Binding key="Secondary-r" action="Mixer/recenable"/> <Binding key="0" action="Mixer/unity-gain"/> # mixer.bindings specific <Binding key="Up" action="Mixer/increment-gain"/> <Binding key="Down" action="Mixer/decrement-gain"/> <Binding key="Left" action="Mixer/scroll-left"/> <Binding key="Right" action="Mixer/scroll-right"/> <Binding key="Primary-x" action="Mixer/cut-processors"/> <Binding key="Primary-c" action="Mixer/copy-processors"/> <Binding key="Primary-v" action="Mixer/paste-processors"/> <Binding key="Delete" action="Mixer/delete-processors"/> <Binding key="Return" action="Mixer/toggle-processors"/> <Binding key="Primary-a" action="Mixer/select-all-processors"/> <Binding key="Slash" action="Mixer/ab-plugins"/> <Binding key="Escape" action="Mixer/select-none"/> </Press> </Bindings> <Bindings name="Processor Box"> <Press> <Binding key="Delete" action="ProcessorMenu/delete"/> <Binding key="BackSpace" action="ProcessorMenu/backspace"/> <Binding key="[0-9]" action="Enter-processor-controls-value"/> # this mockup command uses numericals as regexp and could be used to type in a specific value when input focus is on a specific inline processor control. Otherwise "0" would set unity-gain. <Binding key="[a-z]" action="Select-processor-control-by-name"/> # this mockup command uses the letters of the alphabet as regexp to search and focus, in order displayed by the processor modules section, the title of the desired processor or parameter by title. Letter by letter. Kind of like searching for plug-ins in the plugin manager window. <Binding key="Slash" action="On-Off-processor-parameter-switch"/> # as a processor-box.bindings duplicate of the same keybinding in mixer.bindings, this would toggle ON/OFF any plug-in parameter that currently has keyboard input focus be it momentary (while held) or as a typical switch. If keyboard input-focus is 'not' on a an applicable parameter then it defaults to the mixer.bindings definition. Well, that's it for now. If any of these ideas gain traction, I'll gladly help out in whatever else way I can. |
|
|
Most HCI guidelines strongly disavow overloading keybindings. It creates a very heavy cognitive load on the user. We've done some overloading already, with the excuse that they MOSTLY apply to different tabbables/windows. Even this is not entirely true, since the bindings in the processor box are separate from those in the rest of the mixer window. In general I'm pretty much against in-window overloading, which seems fundamental to what you're suggesting. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-07-06 06:11 | BigstevE | New Issue | |
| 2016-07-06 07:17 | BigstevE | Note Added: 0018276 | |
| 2016-07-06 07:27 | BigstevE | Note Edited: 0018276 | |
| 2016-07-06 07:29 | BigstevE | Note Edited: 0018276 | |
| 2016-07-06 15:21 | BigstevE | Note Edited: 0018276 | |
| 2016-07-06 15:25 | BigstevE | Note Edited: 0018276 | |
| 2016-07-06 22:07 | paul | Note Added: 0018277 |
