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 allows to special-cases session-specific control-surface state.
e.g. midi-learn.
Only restore midi-learned, session-specific, bindings when loading a
session with generic-midi enabled.
Also dis/re-enable generic-midi resets midi-learned, but no other
session-independent settings.
This also handles the edge case:
1) load global config, generic-midi = ON, w/ bindings.
state is remembered as cpi->state
2) load session-condig, generic-midi = OFF, cpi->state is retained
3) user enables the surface, cpi->state from (1) is applied.
-> invalid bindings applied -> fail
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.
This reverts commit 561c8eea0c.
It is rare that a device needs sysex-initialization every time it is
connected, besides a single simple "Sysex" entry without options
is not very flexible.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
The Editor continues to notify them, but via a direct call to ControlProtocolManager, not a signal.
The CP Manager calls the ControlProtocol static method to set up static data structures holding
selection info for all surfaces and then notifies each surface/protocol that selection has changed.
When there are some non-released MIDIControllables, signal are still
delivered to the objects, even if there's no surface thread to handle
the signals anymore.
- GMPC does not use it directly
- when GMPC was enabled Stateful::loading_state_version was set to 1000
(the protocol is at 1.0.0)
- it messes up session-loading, particularly various plugin states and
templates (e.g Processor::set_state_2X was used)
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.
