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 fixes a bug that can result in inconsistent session-state when
copying plugin state from one plugin to another (via drag/drop
ProcessorBox::object_drop, LINK).
The underlying plugin state and settings are copied, port _shadow_data
is updated, and ::get_parameter() shows the correct new value.
However the Controllable was not updated. On Session save/restore
the value may have be lost or was inconsistently restored.
This addresses issues with session-cleanup and region-cleanup in
some sessions.
The root-cause why some unused playlists were saved in the session XML
under <Playlists> and not <UnusedPlaylists> is not known.
Early 6.0-pre did incorrect reference counting, but also older sessions
had this issue. Perhaps due to ambiguities of matching playlists
by name in 5.x or session-format changes 3.x .. 5.x.
Both Disk-reader and Disk-writer use the same playlist.
ARDOUR::Track::use_playlist() sets it for both Disk-IO processors,
so it needs to be released by both on destruction.
Since upcoming state-machine transitions are done in rt-context
via ARDOUR::Session::process_event () they should all in rt-context.
set_session() is called from the UI thread (and the process-lock wasn't
even taken)
Revert this once transport state machine waits for de-click!
This causes audible-clicks on stop, but prevents audible artifacts
on LocateRoll with the current transport-control-logic.
During session load, all earlier configure_processors() calls
were useless and not taking I/O into account! The Delivery ::pan_out()
needs _output I/O ports in order to correctly report the correct
port-count!
This worked in earlier versions because Config->map_parameters()
triggered [two] processor re-configs via ::listen_position_changed().
That behavior was changed in 1af123465c
