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.
This can happen when starting Ardour with the Preference pane
as initial tab. The editor, mixer are not realized, so
-propagation fails with:
IA__gtk_widget_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
