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.
Ardour MIDI tracks unconditionally remember any
MIDI CC/Patch changes that are received.
Patch changes are re-played after the session is loaded,
so that they can reach external synths after ports are
re-connected.
This can lead to issues with synth plugins. Their state
is set first. Receiving a patch-change may alter the synth's
state.
Particularly on macOS child process ReadStdout
may produce many partial lines unbuffered lines.
Since each log message appends a newline, the log
had entries like:
```
Thi
s is a
n examp
le
```
Even for a 32-bit build, MSVC expects 'time_t' to be 64-bit - whereas Glib (i.e. GStatBuf) seems to be using a 32-bit version. Since we're passing by address, this will cause problems in a Windows build.
We can kludge this by making sure we pass the expected type for 'time_t'. Ultimately though, it'd be safer to adapt 'localtime_r()' to accept its first parameter by value, rather than expecting a pointer.
This now passes all of the following, either
when directly bouncing or when re-recording via physical loopback:
* record w/preroll
* record w/count-int
* loop record at 00:00:00
* loop record starting >> 00:00:00
* punch record at 00:00:00
* punch record > 00:00:00
* rec-arm while looping (!)
* repeatedly rec-arm/disarm while rolling
