Playlist::_split_region copies the region and BBT_Time member is default
constructed so position is bar 1 beat 1.
The regions sample position is then initialized to the new position using the
property list.
Playlist::add_region_internal is then used to add new regions to the playlist
which calls region->set_position() but as the region position has already been
initialized it does not recompute the _bbt_time member based on the new sample
position.
Then when a tempo change occurs and Region::update_after_tempo_map_change is
called the default initialized _bbt_time member is used to incorrectly
determine the new sample position.
So the change removes the initialization of the new region position using the
property list initialization method and just lets the playlist set the position
of the region in Playlist::add_region_internal so that the region _bbt_time
member is recomputed in Region::set_position_internal.
This one is debatable, but since we know that the filter method is const with respect to the AUPluginInfo
object, the const_cast<> seems like the simplest AND cleanest solution
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
Currently this code isn't reached because we never call ControlProtocolManager::teardown() on inactive protocols. But at some point it might be appropriate to unload modules (.so/.dll/.dylib) even if the protocol was never instantiated
This new design will work even when threads that need to receive
messages from RT threads are created *after* the RT threads. The
existing design would fail because the RT thread(s) would never
be known the later created threads, and so signals emitted by the
RT thread and causing call_slot() in the receiver would end up
being enqueued using a lock-protected list. The new design ensures
that communication always uses a lock-free FIFO instead
