(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.
When the GUI is opened the first time all is fine, focus is on the
embedded widget. However once a user presses one of the preset buttons
(Add, Save,...) there is no possibility to return focus to the
embedded widget. Ardour always 'sees' it as focus=GtkButton and passes
the event to the editor.
