The pre-nutemo code used fmod() to calculate the offset into the bar:
`bar_fract = fmod (barbeat, 1.0); // fraction of bar elapsed`
with nutempo, beats start at 1, and the tick offset must also be
taken into account.
The bug was introduced in f67029bd0
PortIndex is sorted by name, and uses port-name as unique identifier.
Ports can be re-named concurrently with processing.
::set_port_name() updates the RCU in the background. The engine
may concurrently process with an old RCU reader value.
In this case valid_port() failed in the process-callback.
and ::get_buffer() returned NULL
is_button2_event() was used to detect the user's desire for a
momentary-click on some buttons (mute, solo, mixer scenes)
is_momentary_push_event() disambiguates this action from is_button2_event()
for the special case of momentary, we can drop the workarounds for
the lack of middle-mouse buttons on Mac, and instead just use
shift+left-click on all platforms.
When TempoMap::copy_points() is called, the new points are intended to belong
to the (nascent) new map. But the copy constructor for the points leaves the
_map member of a Point unchanged, and so the new points reference the old
map (forever!). ::copy_points() must reset each Point to reference the new map.
Refactored the object that has the _map member, so that we could limit access
to its ::set_map() method to TempoMap.
Note that ::find_all_sources_across_snapshots() finds and retains
all sources in the SourceList of other snapshots regardless
if they are used in those snapshots.
A route may be processed before latency-compensation callback
sets the route's output_latency. In this case a random offset
was added to the start/end position (via latency_offset).
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
This is otherwise only caught later in the rt-thread after
scheduling a RealTimeOperation via AutomationControl::check_rt.
There is no need to schedule cross-thread events when the
value is not about to be changed.
This can greatly reduce the number of signals emitted by
restoring a slot, which improves performance and also prevents
the EventPool from filling up with useless events.
It can happen that the EventQueue fills up with
SessionEvent::RealTimeOperation. Those are to scheduled to be
free()ed later the GUI thread via event_loop->call_slot().
However it can happen that the GUI EventPool is full, so the request
to call Session::rt_cleanup, is never executed.
In this case the SessionEvent pool can fill up with RealTime
Operations which remain there permanently.
It can happen that ::get_request() returns NULL if the
EventPool is full. In that case the slot is never called.
In this case the caller can now take action.
Plugins on Apple can be multi-arch (Intel + ARM), or AUs may
be bridged by Rosetta.
A user can also run Intel binary of Ardour or M1 binary on
M1 CPUs on macOS. Each can see different plugins - notably
VST3 plugins that are Intel only can be scanned using the
Intel binary, but are later not available with the M1 build.
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).
The process-graph trigger_queue only needs to call
::prep() and ::run() without knowing any further details.
This is in preparation for using the graph-threads for rt-tasks
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.
