This was just a proxy for libs/evoral/evoral/Event.h. Note that the #define
that controlled allocation that was at the top of the removed header is
replicated in the Evoral header, so there are no semantic changes
This fixed a false-positive "ambiguous latency" warning for
MIDI busses:
MIDI track -midi-> MIDI Bus w/instrument -audio|midi-> master
The master-bus only has audio inputs, so the MIDI Bus'
MIDI out is left unconnected. Its latency does not matter,
it can float freely.
Previously it was assumed to be zero. So the MIDI Bus' input
playback latency range was [0, master-bus playback-latency].
The issue remains if a track is selected by a "fit-selection" action second
last track covers the whole trackview. Then when scrolling one track up, the
huge track disappears and a smaller track follows, that covers a lot less
space.
-> Proper redraw of the track view is still needed.
jack2 can process in parallel with calling a graph-order or
latency-callback, so Ardour takes a lock to update those in sync.
Yet jack2 can also block while port-registrations happen,
and concurrently emit latency-callback from another thread..
Port and connection changes always imply a latency_callback from
the engine. Worst I/O latency is updated directly in
Session::update_latency() which is called from
AudioEngine::latency_callback.
Explicit subscriptions to route->output()->changed() is not needed
to update the worst I/O latency.
Only set_block_size() needs to to update the I/O latency when
the buffer-size changes.
The backend may call update_latency() while at the same time
the auto-connect-port calls set_worst_io_latencies().
The latter already holds the process-lock, so update_latency()
first needs to acquire it, as well. If one already holds the
_update_latency_lock, one must not ask for the process-lock.
---
Previously Ardour's connection manager first took the process_lock
and then waited to the _update_latency_lock.
Meanwhile jack calls latency_callback(), takes the
_update_latency_lock and waits for the process_lock.
Classic deadlock.
LV2 plugins may add a MIDNAM file when they're loaded.
This can be happen concurrently with the MidiPatchManager,
loading the system-wide patch files.
Session load should not be interrupted by the initial
background scan of patch files, which can take a very long time.
We need to allow update_custom_midnam() to grab the _lock.
Previously, `dist` had to be the first argument to waf. If it came in a
different position (e.g. `APPNAME=Ardour ./waf tarball dist`) or
`distcheck` was used instead of `dist`, the resulting archive was named
`noname-....tar.bz2`.
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
Various backends have different strategies for updating latencies,
and different thread semantics for latency update callbacks.
With jack2 it is possible that processing happens concurrently
while port latencies are being changed.
Ardour internal backends emit the latency callback from the
main process thread, serializing latency changes with processing.
Various user actions can also trigger latency changes. e.g.
with a stopped engine it is possible to re-order plugins.
When editing a sends, this allows to unlink send panner via
the panner's context menu.
NB. After 6.0-rc string freeze the context menu needs an update.
So far the text from the Processor Box context menu is reused.
The semantics are that if the user configures things to allow transport commands while
using a transport master, issuing such commands first stops using the master
