do not deactivate the meter in a frozen track

git-svn-id: svn://localhost/ardour2/branches/3.0@12991 d708f5d6-7413-0410-9779-e7cbd77b26cf

diff --git a/libs/ardour/audio_track.cc b/libs/ardour/audio_track.cc
index 293ca0d2c1c941b7d9afd90e67a923e8a350e54b..6161147f4406b443d185e002aa42ad21bfd6c456 100644 (file)
--- a/libs/ardour/audio_track.cc
+++ b/libs/ardour/audio_track.cc
@@ -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));
 

diff --git a/libs/ardour/route.cc b/libs/ardour/route.cc
index 0c233bfc31431f13dad410231debc26632437af1..1a6bff5096a1a6dbfbfd6aca3d880a5db593659e 100644 (file)
--- a/libs/ardour/route.cc
+++ b/libs/ardour/route.cc
@@ -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.
        */
 }