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
realtime_stop() calls unset_play_loop(), unless loop is a
transport-state. Any later calls by butler_transport_work()
will never reach this get_play_loop() clause when just looping.
Besides while recording, locates are not possible,
so this case never triggered under normal operation
(Non-seamless looping is no longer supported since 6.0).
DiskWriter::seek() flushes all recorded audio/MIDI, and resets
buffers as if no recording has happened.
Data must be flushed to disk before any non-realtime locates happen.
This happens at transport-stop, which is usually called first.
Except since 8b048bb351 Session::butler_transport_work() may call
non_realtime_stop() after a non_realtime_locate() when looping
more than once.
If there is a tempo/meter change after the loop-end,
the capture duration was set incorrectly.
Previously `total_capture_beats` was set as if the recording
was linear passing though tempo-map changes after the loop.
_capture_start_sample is remains zero until
DiskWriter::check_record_status() starts recording.
This incorrectly increased _accumulated_capture_offset
during pre-roll which resulted in lost samples at the beginning.
This amends 730a0954 and b27bb586.
This also restores the original API for do_import()
and do_embed() as used by Lua scripts.
Note that this uses distinct IDs when importing both audio
and MIDI in the same DnD request.
