block_processing() may hold the process-lock, waiting
for the latency-lock. at the same time audio-engine
may hold the latter, trying to acquire the former.
This does not maintain note timing, but once the buffer contents arrive at a receiver, it should
be playing all the notes that were marked on in the tracker
When bouncing Region or Range, Session::write_one_track()
blocks processing, but takes no process-lock.
It is possible that a latency-callback arrives at the same
time while Route::bounce_process is active and calls ::run.
This can trigger a delayline.cc Assertion `lm.locked ()' failed
in either thread.
Now latency-callbacks are postponed until the session can
process normally again
process_index should not be compared/combined with expected_end_sample, since
the former is a process-cycle count and the latter is a timeline position.
* first the region is scanned for bpm and one-shot status
* then we handle properties that should be applied from a drag&drop
* then we handle the existing arrangement-style slot properties that should persist
This addresses the issue described in 83719fba1a.
First process all queued self_delete() requests before scheduling
Editor::redisplay_track_views() which uses PRIORITY_DEFAULT.
THe length of a Source(File) is always measured from its start. In this sense,
the length is like a position on the timeline, which is a duration with an
implicit origin, or a Region start, also a duration with an implicit origin (in
that case the start of the Source). There is no good reason for using
a timecnt_t for this value, because the position component of a timecnt_t
(the origin for the duration) is implicit and always zero. So we make
this property into a timepos_t, and include a number of asserts() to check
for common possible coding errors related to the time domain
The length needs to use consistent time domains for duration and position,
and total_capture is a sample count. The "real" length of a whole
file region is the length of its source, so just defer to that.
Session::process_audition calls Graph::swap_process_chain()
to handle any pending graph changes (notably route removal
depends the graph to switch chains to drop references).
However this must not change the Graph::_trigger_queue
(which is refilled when processing resumes).
Previously routes were added to the trigger_queue, leading to
an inconsistent Graph state. When the terminal-count was reached
the trigger-queue was not empty. Process threads ran after processing
already completed and or concurrently with processing.
A common result of that was:
delayline.cc:70: virtual void ARDOUR::DelayLine::run(ARDOUR::BufferSet&, ARDOUR::samplepos_t, ARDOUR::samplepos_t, double, ARDOUR::pframes_t, bool): Assertion `lm.locked ()' failed.
