MidiControlUI drops the reference to a given controllable in
its own thread. This can happen after the plugin is already
destroyed (even though the PBD::Controllable still exists).
Increment for CC values > 0x40, decrement control for values <= 40.
- 0x41 increment by one
- 0x40 decrement by one
previously: 0x3f decremented by one, 0x3e by two, .. 0x00 by 64,
but 0x40 also by 64.
This fixes an issue with "/route/eq/freq/0 S1":
When a newly select strip that does not have a EQ
(e.g. mixbus or master), the control from the previously
selected strip is used. -- Reported by tavasti on IRC.
Add support for smoothing, ignore message when controllers are
not in sync to avoid discontinuous jumps.
This is mainly useful for Mackie-like devices that use pitch-bend
messages for faders.
see also https://discourse.ardour.org/t/feature-lazy-sliders/100961
"last_controllable_value" is using midi value range (0..127).
It is used to compare received midi-value with the actual controllable
for non-motorized surfaces, and this change allows the first
event to already be in_sync.
Previously the first MIDI-event was usually ignored (because
last_controllable_value was out of bounds or didn't match the 0..127
range.
Continued work after e9b36f2bea. Prefer a shared_ptr<>.
MIDIControllable::write_feedback() runs in realtime context, directly
from the main process-thread. Synchronizing weak-pointers and deletion
across threads does not work reliably. Retaining a shared_ptr<> for
controllables that are in use can solve this.
This fixes a race-condition when a controllable is deleted
while sending feedback to the device.
Previously there was a race-condition MIDIControllable::write_feedback()
triggered from rt-thread, processed in Surface-thread and deleting
a route or processor.
This is a first step, currently state-restore is not fully functional
session->controllable_by_id() does not cover all Controllables.
This also removes enums introduced to describe well-known parameters for Mixbus. Lookup now involves string
parsing every time, but this is not likely to be a notable cost.
That commit accidentally removed unrelated code in generic-midi surface
which just happened to have the same name (get/set_midi_feedback) as the
unused preference.
Regardless, there was more cruft there. GMCP midicontrollables now use
the control surfaces' feedback option.
This also removes Route::group_gain_control() and associated machinery.
Not yet tested with Mackie or other surfaces. More work to done to
start using the group capabilities, and also potentially to add
or derive more controls as RouteAutomationControls
