Exporting a dedicated Range should not be constrained by
session markers. This fixes at least 2 issues:
* export could be cut short when using latent plugins
* exporting a range crossing the session end marker was cut short
When starting RangePlay while the transport is already rolling
the transport is now stopped (and de-clicked) before locating.
This should not clear the RangeStop event when it is caused
by a RangePlay request.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Grid controllers will largely want to access clips in the order they appear on the Cue page
It is up to the device (and/or its ControlProtocol) to handle banking
if a slot becomes active, and the transport is not rolling, it still
asks the transport to roll. however, (1) there's only 1 request across
all triggerboxen (2) the request will not be handled till the next
process cycle (3) the triggerbox returns after the request i.e. it
waits until the transport is rolling
There is no longer an extra set of rt-threads, but existing
process-graph threads are reused.
There are two main benefits to this approach: graph-threads
have a SessioEvent pool and ProcessThread buffers. They are
also joined to work-groups (on macOS), or JACK created threads
(cgroups).
Route::silence() runs plugins. With a heavy session
that relies on multi-core processing, sending silence
to processors will have to be done in parallel.
Otherwise it can result in large DSP load and xruns.
This may allow to revert b3497b3f8f, which was
a prior attempt to resolve this, before understanding
the actual cause.
This allows to pass any GraphChain to the Graph to process.
It removes the need to use a mutex to swap two dedicated
chains (setup-chain <> active-chain, pending-chain).
Also various special cases pertaining to graph interaction
while auditioning and route-deletion can be removed.
This also unconditionally creates a graph-thread for GraphChains
to be processed, even if the main callback uses a special-cased
sorted RouteList if there is only one process thread.
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().
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.
Somewhat alarmed that gcc (at least) allows if (cue_recording ...) to be
used just like if (_cue_recording) even though the former is a class method
and the latter is a class member.
This fixes an issue with adding/removing tracks while auditioning.
Session::remove_routes() calls Graph::clear_other_chain(),
which will block until the graph chains have been swapped.
