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.
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.
"scratch buffers are by definition scratch and their contents are undefined at all times"
"silent buffers are by definition all-zero and should not be used for real data"
But track & route were using those for actual data; plugins (which may run
in the same thread and may get the same buffers) use them for scratch thereby
overwriting real data.
In particular get_silent_buffers() (used by LadspaPlugin::connect_and_run)
clears the buffer which can holds real data:
e.g. via Route::passthru_silence() -> plugin1 -> plugin2 (clears output of plugin1)
- replaces fix in 066df0d218
- Check if _LIBCPP_VECTOR is defined for vector_delete.
This is defined in libc++'s headers which Apple is using
instead of libstdc++
before this change:
1) switch to 'custom' meter point,
2) deactivate meter processor.
-> meters does not run regardless of meter-point
-> meter can only be re-nabled in 'custom' mode
..and continue to calculate fall-off in
audio-cycle (rather than UI thread)
TODO: check if this works properly when switching
between audio/midi meter modes on a midi-track.
One of the motivations to always reset meters when the
meter-point changes was to resolve peak-hold & fall-off
issues when a midi-meter replaces an audio-meter and vice
versa.
