Classes derived from AutomationControl now check ::writable() in their ::set_value() methods to ensure that they
do not attempt to overwrite data sent to them while automation playback is underway.
The signal exists to notify listeners that something outside of the host's control (e.g. a plugin's own GUI for AU or VST)
has modified a plugin parameter. Previous code had strange feedback loops and ambiguous semantics.
The signal exists to notify listeners that something outside of the host's control (e.g. a plugin's own GUI for AU or VST)
has modified a plugin parameter. Previous code had strange feedback loops and ambiguous semantics.
Significant modification of LV2 GUI updating was required.
Still to be tested for feedback loop issues: AudioUnits
Prepare for proper processor-box wire-display:
Don't replicate connection-logic in the GUI, allow to query the
actual configured configuration (which may differ from the processor
i/o-streams)
when copying a plugin the state is transferred by serializing
XML and setting state from XML. This state includes the unique ID.
This ID needs to be identical at first in order to load
the state from <session-dir>/plugins/<ID>/*
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
e.g. Audio in -> Midi out plugins (on an audio-track).
Midi-buffers do exist in the route but no corresponding
(physical) Input port-buffer exists and ardour crashed.
Now, the plugin itself still only accesses the mapped ports
(ChanMapping), but the mapped buffers are at most
"processor_max_streams" and at least the required
in+out buffers for the plugin.
fixes possible x-talk 1 in, >= 2 out tracks:
Previously, only the first route-buffer of the input buffers
were marked as non-silent in Route::process_output_buffers().
Other buffers in the set (e.g. post-panner) would
contain audio but not marked as non-silent.
* 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.
It's slightly possible that this causes trivial build failures on different
configurations, but otherwise shouldn't cause any problems (i.e. no actual
changes other than include/naming/namespace stuff). I deliberately avoided
removing libardour-config.h since this can mysteriously break things, though a
few of those do seem to be unnecessary.
This commit only targets includes of ardour/*.h. There is also a very large
number of unnecessary includes of stuff in gtk2_ardour; tackling that should
also give a big improvement in build time when things are modified.
git-svn-id: svn://localhost/ardour2/branches/3.0@12420 d708f5d6-7413-0410-9779-e7cbd77b26cf
