the goal is to allow a clear demarcation of where we need
the audioengine and have existing data parameters (e.g. sample rate)
for the session so that we can coerce the engine (if possible)
to match to session values.
also, to rationalize construction even more and use C++
constructor syntax as much as possible.
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.
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.
gtkmm2ext/keyboard.cc has a special case to emit a signal on the key-up of
the modifier key used to adjust track heights in conjunction with the
scroll wheel, so that the same track continues to be resized even when
it's shrunk to no longer be under the mouse cursor. However, this code
assumed that the modifier key for this was <Shift>.
Fix it to use the event->state bit corresponding to
ScrollZoomVerticalModifier instead, and rename the relevant functions to
clarify that it's the 'zoom vertical' modifier key they're dealing with.
Partially fixes#5610.
