Issues remain with the basic model of the AMS dialog - when is
newly chosen state pushed into the backend (which can then
modify the control app button sensitivity. This is a special
problem for this button because APIs like ASIO and CoreAudio
probably don't allow us to launch a control app for an arbitrary
device, but only one actually in use. In this sense it is
different from properties like available buffer size etc, where
we can typically query without actually using the device.
This was caused by using jack_port_get_connections() which will
not return the correct status for ports owned by another JACK
client. Because of the potential for deadlock by calling
jack_port_get_all_connections(), an extra argument was added
to several PortEngine:: API calls to specify whether the call
is in a process-callback context, which defaults to true.
The only place where false is passed is within the GlobalPortMatrix
when we need to determine whether two non-ardour ports are
connected.
This makes the responsibilities and ownership of non-Route related MIDI ports
more clear, and removes a few wierd bits of code. It also ensures that open/close/open
on the same session will retain connections for those MIDI ports
amend to 4cdb018 and 1d972d0
override ui_closed() behavior for lv2ui:external
Keep UI around and do not re-instantiate, but simply show it again.
(this is against the original specs but was agreed upon by various
authors and the previous behavior or Ardour.)
kx:external-ui are cleaned up after ui_closed().
threads created with this code can now just return a value as they normally would, and the
infrastructure will ensure cleanup. there is no longer any reason to call pthread_exit_pbd()
and so that has been removed.
incoming MIDI data has to be parsed EVERY process cycle, not just when Slave::speed_and_position() is called.
The private MIDI::Parser owned by the MTC and MClck slaves was irrelevant, since the port has its own.
See comments in midi_port.h on the strangled inheritance heirarchy.
This is not thread safe of course, it is not intended to be.
This was implemented as at one stage ARDOUR::init was being called multiple
times in the testsuite which was causing a subtle bug that took some
time to track down.
