Some modern keyboards spread out patches over various banks,
and group them using explicit "PatchMIDICommands".
A given PatchBank does not have a common MIDI Bank.
Previously those PatchBanks were not listed in the MIDI Patch
Selector, which is based on MIDI Bank + Program grid.
The current view is some sort of compromise, retaining a
per MIDI-bank view, but allowing Monatages/performance mappings.
The Patch Change *dialog*, or dropdown is more useful for those
sparse modern mappings.
This fixes an issue with a-Amp interpolating the parameter in dB,
resulting in a double-exponential fade when the parameter changes.
Now fade is linear in dB, also using Ardour' Amp processor is more
efficient, since interpolation happens in C++.
Unconditionally use the mouse-cursor as zoom-focus when holding
<ctrl> while scrolling on the canvas.
This is consistent with using ctrl + scroll in the ruler area.
add methods to callback.js
automatically reconnect js client on disconnection
mixer-demo do not recreate UI on reconnection
NO-OP: indentation in message.js
make client JS reconnection optional
fix mixer-demo scrolling
minor JS client refactor
improve mixer-demo readability
When Prefs > Editor > Zoom to mouse position... is disabled.
Ctrl + Scroll now allows to override the current zoom-focus,
and zoom in/out at the mouse-cursor position.
1. Alt is still handled to change drag behavior
2. Selection doesn't store notes unless they are part of the cut buffer, which means we should not
be altering the note selection in the editor's selection object most of the time.
1) Notes are only present in a Selection object if it is being used as a cut buffer. They are never stored
there as part of "normal selection" - that is delegated/left to MidiRegionViews that own the notes.
2) MidiRegionViews are stored in the Selection as "just" RegionViews, so provide a convenience
method to access them. This doesn't actually change much, since even the old MidiRegions object
was actually just a RegionSelection i.e. RegionViews.
We now check from the focus widget (if any) for any widget heirarchy bindings, and try to use them.
Next use the "top level" bindings passed in (top level is quoted because they may be owned by a tab,
rather than a window).
Finally, if the event is still not handled, try the global bindings
This model more closely matches what I think a reasonable programmer with experience of other
GUI toolkits would expect, and allows us to have multiple bindings present (though not
simultaneously used) in a given window
This allows "stacking" of bindings by desensitizing the actions associated with a "lower" level
of bindings at certain times (e.g. MIDI editing bindings thare are sensitized in the appropriate
editing modes
