It was possible that auto-connect-thread or GUI thread called
DelayLine::set_delay without acquiring the process-lock.
Changing the delay while processing is not supported and
can cause glitches.
backtrace:
```
DelayLine::set_delay
Send::update_delaylines
Send::set_delay_out
InternalReturn::set_playback_offset
Route::update_signal_latency
Session::update_route_latency
Session::update_latency_compensation
Session::auto_connect_thread_run
```
There is no event processing after the locate, and so the event that is (was)
queued at the loop start will not be processed, and each time we reach the
loop end, we will try (and fail) to queue an identical event (fail because
duplicate events are not allowed). We don't need this event (or signal) at
all, because locates (and then ::start_transport() while looping do not
represent a state change that any UI needs to know about.
The previous idea was to follow Ardour's default
\delta val = \delta Y - \delta X
In reality it turns out that this is better represented
with kLinearMode.
VST3 offers the following:
* Circular with jump to clicked position
* Circular without jump to clicked position
* Linear: depending on vertical movement
The first is right out. Value changes need to be
continuous. The last explicitly mentioning vertical
movement was also somewhat discouraging,
however most plugins don't take it literally and allow
linear X/Y movement.
existence_check() calls prevent_deletion() -> mark_immutable()
which since a4d7b45fe0 calls close().
So the file needs to be open()ed after the existence check.
TransportStateChange() triggers various updates.
However at the time the signal is handled
`transport_rolling()` and/or `transport_state_rolling()`
may still return false.
This fixes incorrect In/Disk display on tracks (RouteUI)
and incorrect automation write-pass handling,
when toggling stop/play.
This is for at least two reasons: transport will effectively
move with 32 samples * 6.25% = 2 samples per cycle and the
resampler cannot up/downsample a factor of > 16 with
reasonable quality.
This happens with e.g. the IEM suite when a user has both
/usr/lib/vst and /usr/lib/lxvst in the search path.
The same plugin was found twice due to symlinks:
```
/usr/lib/lxvst/iem.at -> ../x86_64-linux-gnu/iem-plugin-suite/vst
/usr/lib/vst/iem.at -> ../x86_64-linux-gnu/iem-plugin-suite/vst
```
And then blacklisted itself:
> "Ignoring plugin 'MultiBandCompressor'.
> VST-ID conflicts with other plugin 'MultiBandCompressor' files:
> '/usr/lib/x86_64-linux-gnu/iem-plugin-suite/vst/MultiBandCompressor.so' vs
> '/usr/lib/x86_64-linux-gnu/iem-plugin-suite/vst/MultiBandCompressor.so'
* use dummy-backend (don't expect engine to be running)
* add required TestUI / Receiver
Lots of regions: add scope to prevent SessionHandleRef
existing across session deletion
RunPC: take process-lock before processing, prevents various
assert() and concurrency issues.
Print a less cryptic error message in case the wrapper app
cannot be found. Also address a future race condition (once
we start parallel plugin scans and will exec-wrapper from a
helper thread).
If there are multiple connections, one might fail due to missing hardware,
but the rest could still be valid.
An easy way to reproduce this was to route "mackie control out" to a device
and to the Midi tracer port. When you opened the session again, connection
from the "mackie control out" to the device would not get restored because
the Midi tracer port does not exist at session start.
This most likely caused other issues with connections when changing backends.
