This avoids stuck notes if active notes are edited, but without stopping all
active notes in the region on any edit as before.
This implementation injects note ons in places that aren't actually note
starts. Depending on how percussive the instrument is, this may not be
desired. In the future, an option for this would be an improvement, but there
are other places where "start notes in the middle" is a reasonable option. I
think that should be handled universally if we're to do it at all, so not
considering it a part of this fix for now.
Towards putting more advanced logic here, where two copies of everything will
get even more hairy.
The two cases of reading from one or many regions are not very different in the
read phase, the only difference is the target. So, point a reference to the
appropriate target, use the same read code in either case, then sort/etc
afterwards only if necessary.
(hopefully) fixes export randomly stalling on windows:
dequeue_request() was a single request (no queue) on Windows.
Butler::queue_request() is called
-> Butler goes to work..
-> while working, another request is queued
-> butler never sees this
-> deadlock
during Freewheeling/Export wait_until_finished()
waits for the 2nd request to be handled, and never returns.
MidiPort::cycle_end() was never called, hence after the
first cycle all midi buffers were assumed to be
“mixed down” already.
this fixes
Midi-track 1 -[midi]-> Midi-track2 synth -[audio]-> out
on export.
Ardour calls input_streams(), output_streams() to determine
if the plugin is about to be re-configured (old stream I/O count
!= new I/O count) and emit PluginIoReConfigure() if that’s true.
If the plugin has not been initialized (no format set), we can
safely assume that it will need to be reconfigured.
Forcing Audio=Midi=0 will do so.
The only time where the format is not yet set and hence the actual
channel count is still unknown) is during the first call to
PluginInsert::configure_io().
At the time of writing, this all is a NOOP anyway! The only user
of the PluginIoReConfigure() signal is the GUI to update connection
lines… and since the first PluginInsert::configure_io() happens
during insertion before the plugin is painted and subscribed to
PluginIoReConfigure(), this function could return any value.
Still 0,0 is just more appropriate than assuming mono audio in/out
and no midi.
It is less likely that these would cause issues because the
variables involved define the size of the data read, which
is almost certainly less than the 32 bit limit (i.e. they are
not positional). But to keep things clean and to keep questions
at bay, make them 64 bit values.
