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 reverts most of 50c555f1a1
* Never render from `map_transport_state()` callback
* re-instantiate deadzone, only update when last_speed_displayed
differs by 0.5%
* Fix Pool OOM due to mapping state doing direct UI changes
instead of delegating this to lower priority render()
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.
* localize speed changes into varispeed dialog
* make speed-changes idempotent
* remember window position (do not overlap with button)
ideally the window would show up below the "Vari" button
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'
Since 80c11a763a the GUI is notified when the xrun counter
is reset (previously the rec-ui xrun counter never returned
to zero).
However when create-xrun-marker is enabled ARDOUR_UI::xrun_handler
tried to create a marker at -1 which causes various issues.
* 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.
