TempoMap::use() assumes the thread_local pointer has been set up. This
is not the case for the control protocol event loop, so call ::fetch()
instead which does not require this assumption (and sets the thread_local
pointer too, though nothing else in the Mackie code uses it)
This also required a mechanism to prevent the fact of a non-null "currently_playing" value in
the TriggerBox from starting the transport, which is handled with Triggerbox::_locate_armed. This
is set when _currently_playing is set from TriggerBox::fast_forward()
In order to detect if route delaylines need to be updated,
aux-send delaylines need to be updated first. This was previously
done directly in the latency-callback, which may be concurrent
with processing.
Now only the information (pending_delay) is set, and the actual
change happens later at the end of process().
Due to _init_countdown when the engine starts, it is
extremely unlikely that Session::initialize_latencies(),
which is invoked by AudioEngine::Running runs concurrently
with Session::process, but at least in theory it would be possible.
This reverts commit 220b1386ab.
because it causes crashes when saving sessions.
_channel_map[] must not be empty, otherwise
Program terminated with signal SIGSEGV, Segmentation fault.
snprintf (buf, sizeof (buf), "%d", _channel_map[chn]);
#0 ARDOUR::MIDITrigger::get_state() (this=0x55d676b4c600) at ../libs/ardour/triggerbox.cc:1962
#1 0x00007f58ccb40b12 in ARDOUR::TriggerBox::get_state() (this=0x55d676b4d720) at ../libs/ardour/triggerbox.cc:33
Calls DR::set_pending_overwrite() sets DR::run_must_resolve
before the first run.
Previously this variable was set after the first ::run,
which resulted in notes at the beginning of audition to be
cut short.
Previously events with different reasons where treated as two
separate events. Processing an Overwrite request causes
post-transport-work to set.
Since ::non_realtime_work_pending() is true, process_event()
is not called, and no further immediate events are evaluated in
the same cycle.
So Overwrite requests were repeated over multiple cycles.
Files that have many tracks, each with tempo information
were near impossible to load (30+ mins on modern 4.2Ghz CPU!),
because tempo is parsed incrementally:
```
For each new track:
for each new tempo-event:
rewind()
for each loaded track so far:
for each event on this track so far
```
This reduces the complexity from O(tracks^2 * tempos^2)
to O(tracks * tempos).
"Come Thou Fount Tempo Map.mid" has 238 Tracks and 56168 total
Tempo Changes (236 per track). This now requires only 56168 iterations
in smf_create_tempo_map_and_compute_seconds, rather than 1.64e+9
iterations
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
