ardour/livetrax
13
0
Fork 0
Code

do not deactivate the meter in a frozen track

Browse Source 
git-svn-id: svn://localhost/ardour2/branches/3.0@12991 d708f5d6-7413-0410-9779-e7cbd77b26cf
This commit is contained in:
Paul Davis 2012-07-06 19:18:33 +00:00
parent 0dc992bcf7
commit f110126fca
2 changed files with 32 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
libs/ardour/audio_track.cc
View File

@ -672,7 +672,7 @@ AudioTrack::freeze_me (InterThreadInfo& itt)
for (ProcessorList::iterator r = _processors.begin(); r != _processors.end(); ++r) {
if (!(*r)->does_routing()) {
if (!(*r)->does_routing() && !boost::dynamic_pointer_cast<PeakMeter>(*r)) {
FreezeRecordProcessorInfo* frii = new FreezeRecordProcessorInfo ((*r)->get_state(), (*r));

35
libs/ardour/route.cc
View File

@ -309,11 +309,35 @@ void
Route::set_remote_control_id_from_order_key (RouteSortOrderKey key)
{
if (is_master() || is_monitor() || is_hidden()) {
/* hard-coded remote IDs, or no remote ID */
return;
}
uint32_t n = order_keys[key];
/* we have a nasty glitch in an otherwise fairly clean system here.
in theory, a route's remote control ID is determined by the order
key matching the current remote model (for UserOrdered, the user
controls everything). its one greater, because order keys are zero
based and remote control IDs start at one.
but ... an order key for the master bus may place it before or even
within normal routes, yet its remote control ID (like the monitor
bus) is hardcoded to MasterBusRemoteControlID. this means that all
routes ordered after it (in whatever controls the EditorSort or
MixerSort ordering) will end up with a remote control ID that is one
too large.
we therefore check on the master bus ordering, and adjust
later-sorted routes remote control ID to avoid this "off by one"
error, which keeps remote control ID's contiguous and "right".
ideally, this would be done in a UI layer, where this logic
is really understood and has meaning, rather than in libardour where
its fundamentally meaningless.
*/
switch (Config->get_remote_model()) {
case UserOrdered:
break;
@ -344,10 +368,13 @@ Route::set_remote_control_id_from_order_key (RouteSortOrderKey key)
break;
}
/* don't emit class-level RID signals here, leave that to the entity
that changed the order key, so that we don't get lots
of emissions for no good reasons (e.g. when changing all
route order keys)
/* don't emit the class-level RID signal RemoteControlIDChange here,
leave that to the entity that changed the order key, so that we
don't get lots of emissions for no good reasons (e.g. when changing
all route order keys).
See Session::sync_remote_id_from_order_keys() for the (primary|only)
spot where that is emitted.
*/
}