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.
Best to just do this as early as possible to avoid having to deal with this
situation all over the code.
Also fixes violation of LV2 MIDI specification, which requires no such events
are delivered to plugins.
Silly to make a junk Note just to pass to append_note_off_unlocked, which just
uses the fields that are on the MIDIEvent anyway then throws it away.
Also explicitly dispatch to append_note_off_unlocked in the caller for note ons
with velocity 0 rather than make append_note_on_unlocked deal with it.
Session::unset_play_loop() needed to be a no-op if play loop was
already false, and this was exacerbated now that it potentially
schedules butler transport work.
Try to make sure that we appropriately reset and refill track
buffers whenever we enter/leave loop playback,and whenever
we locate. In addition, if we start playing somewhere other
than the loop range while loop is enabled, then the first
time we hit the loop end, set up the track buffers.
Conflicts:
libs/ardour/session_transport.cc
