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.
Issue #6280 states that when selecting ranges using SnapToRegionBoundary it's
not possible to select regions with first_frame() == 0. This is because
Playlist::find_next_region() does not consider region boundaries == pos but
only > pos. Thus it never considers pos == 0 to be a region boundary.
This solution tries to be as little invasive as possible without changing the
semantics of PlayList::find_next_region(). Therefore position 0 is added to the
region boundary cache if there's a region starting at position 0 in any track.
a-Inline Spectrogram used a ringbuffer to send mixed down audio data
from the DSP thread to the inline display thread. The problem is that
several inline display threads can coexist (one for the channel strip in
the editor, one for the channel strip in the mixer, and soon one for an
inline display in the generic plugin UI). A ringbuffer is single-writer
single-reader so each display only got part of the data, and all were
competing for it.
Replace it with a circular table, where the DSP sets a write pointer,
and every (inline display) user keeps its own read pointer and checks it
is not so far in the past as to be overtaken by the DSP write pointer.
* 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)
Editor::redisplay_tempo() is called early on, before
Editor::set_timecode_ruler_scale() and Editor::compute_bbt_ruler_scale ()
are called. That is a bug which needs fixing (initial tempo+grid display)
. Still, uninitialized vars are not good.
