When using bounce w/process, the initial bufferset can [wrongly] be
buffers.set_count (track.max_processor_streams())
Since the polarity-processor is first in the chain, iterations
over all buffer that don't have a matching _current_gain[]
or _control[] leads to memory-corruption or segfault.
This fixes a bug when shift() creates automation for parameters that
can not have any automation (hidden parameters, Mixbus PRE).
The GUI (RTAV) aborts() when it finds an automation lane for
a hidden parameter.
This also cleans up shift() operations in general. Empty automation
lanes should be left alone, no guard-point at zero should be added.
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.
Session::Controllables is a shared_ptr<> list. As long
as the session exists the Controllables will be around. Destroyed(*)
can only be called after the session is destroyed and releases the
shared_ptr<>
NB. this code had a nice hack to construct a "shared_from_this"
workaround. For future reference:
struct null_deleter { void operator()(void const *) const {} };
boost::shared_ptr<Controllable>(c, null_deleter())
To facilitate a central registry with weak/shared pointer lookup,
enable_shared_from_this<ARDOUR::AutomationControl>
was migrated to
enable_shared_from_this<PBD::Controllable>
The main (and only) user is generic-midi surface's state interface :(
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.
