If the width of the display area is below 200 px, we switch from the graph
display to displaying only two bars, one for output level and one for gain
reduction. In the bar mode we also visualize threshold and ratio.
When lifting the compressor curve by the makeup gain value the actual
treshold (the level when the curve kinks in) is also lifted. Therefore we need
to adjust the dashed line indicating the threshold as well as the level when
the color gradient to show compression kicks in.
This fixes a crash with GUI elements which are only deleted during GUI
Idle and hold a Reference to a Controllable,
The session is already destroyed at that point:
ARDOUR::CoreSelection::remove_control_by_id(PBD::ID const&)
ARDOUR::AutomationControl::~AutomationControl()
ARDOUR::SlavableAutomationControl::~SlavableAutomationControl()
ARDOUR::MonitorControl::~MonitorControl()
boost::detail::sp_counted_base::destroy()
boost::detail::sp_counted_impl_p<AudioGrapher::Interleaver<float>::Input>::dispose()
boost::detail::sp_counted_base::release()
boost::detail::shared_count::~shared_count()
boost::shared_ptr<PBD::Controllable>::~shared_ptr()
boost::shared_ptr<PBD::Connection>::~shared_ptr()
ArdourWidgets::BindingProxy::~BindingProxy()
ArdourWidgets::ArdourButton::~ArdourButton()
VCAMasterStrip::~VCAMasterStrip()
int idle_delete<VCAMasterStrip>(VCAMasterStrip*)
Ardour follow_slave() does nothing (not even seek) if the slave is not
locked.
The LTC-slave assumes it's locked if LTC is stable for 5 continuous
process-calls.
If the difference of Ardour's transport-position to the LTC-timecode
is large (> 2sec), the slave reset itself (assuming drift, seek don't vari-
speed).
A LTC-slave does reset does reset the locked counter.
Hence: If initially Ardour's transport differs > 2 sec and the buffersize
is small (many process-callbacks), the slave kept resetting itself
never informing Ardour that it locked to the external TC, and Ardour
never issued a seek.
* lock list when editing (prevent concurrent modification of insert
iterator
* don't add a guard-point if an event is already present between the
target and guard-point-position
* remove existing automation-events (old guard points) when
touching automation w/o change
* don't unset "new write pass" when not rolling
(fixes issues when not rolling but locating with write-enabled)
This calls for a unified API to invoke
Automatable methods ::transport_located() and ::transport_stopped()
on Stripables, rather than indirectly calling it via
Route::non_realtime_locate(), Route::nonrealtime_handle_transport_stopped()
