"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)
fixes crash:
- add bus
- aux-send a signal to that bus
- delete bus
- add another bus
- aux-send a signal to "another bus"
- click "Aux Send" button on "another bus"
- crash
- 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++
- MIDI driver options are now "None" and "coremidi" on OSX
- If coremidi is selected, jack will start with midi activated
- Requires Jack OSX version 0.90 beta 15 (or another version that
supports midi
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.
