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.
i've made the audiobackend call the session directly so that only one object (ARDOUR::Session) has a need for the JACK types
and only one .cc file (session_jack.cc) needs jack.h. having ARDOUR::AudioEngine act as an intermediary would be cleaner
conceptually but would end up causing two different ARDOUR objects to have jack types in their own API.
if sub-frames are used, frames are rounded up for the later half of
a sub-frame. e.g. @48KSPS, 25fps, 100 subframes per frame
audio-samples >=1910 already yield 00:00:00:01
bug:
- add midi track
- add additional midi port
- remove additional midi port
- press play
-> crash
because..
ARDOUR::MidiTrack::roll's route_buffer still has 2 midi-channels. This is
because processor_max_streams was not updated (no plugins added/removed)
fill_buffers_with_input() eventually asserts when trying to get the 2nd
(nonexistant) midi port via ARDOUR::PortSet::nth_midi_port() in
ARDOUR::PortSet::port().
fixes loading a session with tracks that have more input-ports
than output-ports.
the problem:
input -ports are added first, when added, IO::ensure_port() emits
IOChange::ConfigurationChanged which in turn triggers the route to
allocate corresponding output ports.
Due to this callback the output-ports were created before the actual
output-port-configuration and plugin-configuration from the
session-state was parsed and set.
do not allow port-removal if the port would be re-added immediately
after that again because the main-delivery actually needs it.
As a side effect this prevents this crash:
* create a stereo-track, then remove one output
-> unhandled exception "AudioEngine::PortRegistrationFailure&"
The problem:
- the port is removed from the RCU ports list,
but Port::drop() (which calls jack_port_unregister) is only called
from the Port's destructor at some later time.
(because a reference to the port still exists elsewhere)
- the jack-port is not yet removed.
- meanwhile Delivery::configure_io comes along and notices that
there are more audio-buffers than ports and tries to re-register the port.
- but the port still exists in jack, so it fails and throws an exception
...which is not handled.
* forward midi-data around plugins that have no MIDI-out
* allow to insert plugins with no MIDI-input at a point with one MIDI-channel
This works because excess ports (both plugin and route) remain
unconnected and use scratch-buffers.
Tested with LV2, LXVST and LADSPA.
(AU plugins with variable in/out retain the old behavior, no bypass)
fixes http://tracker.ardour.org/view.php?id=5630
Plugins rewrite the buffer data in-place and some plugins
can produce output even when fed with silence.
Hence, during a PluginInsert::silence() run a plugin can
inject data into the "silent" buffers which causes side-effects.
Kudos to Chris 'oofus' Goddard for finding this issue.
