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.
- Do this instead of finding them in the static ctor of LV2World
- Prevents usage of ARDOUR_DLL_PATH environment variable before
it is set in main(...)
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().
