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.
(bool) false == 0 == (const char*) NULL
error: ISO C++ says that these are ambiguous, even though the worst
conversion for the first is better than the worst conversion for the second:
actions.h:92: note: candidate 1: Glib::RefPtr<Gtk::Action> ActionManager::get_action(const char*, const char*, bool)
actions.h:91: note: candidate 2: Glib::RefPtr<Gtk::Action> ActionManager::get_action(const std::string&, bool)
For MSVC, the parameter 'false' (i.e. 0) can be considered as either a bool or a pointer - so it'll map to both declarations of ActionManager::get_action()
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
