This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
This allows to distinguish Processor::configure_io from the
Plugin API with the same name. Despite the identical name,
both functions serve different purposes.
Likewise the ::can_support_io_configuration() API is renamed.
The signature of that function call has already diverged.
The Plugin-API has to handle optional busses (e.g. side-chain)
and replication. The PluginInsert processor provides context.
This change is in preparation for AudioUnit and VST3 busses.
Currently a stereo-input (1 bus) cannot be distinguished from
mono + sidechain (2 busses).
This fixes a circular shared_ptr<> reference that prevents
plugin destruction.
LuaProc may hold references to Route that contains the plugin
or the PluginInsert of the LuaPlugin. These are only dropped
when the interpreter collects garbage.
Previously this happened in the d'tor or LuaProc, but while the
Plugin has a reference to the Insert, the Insert is not deleted
and the d'tor is never called.
This reverts commit 8702ff2189,
and b10d9cf09b.
There was a misconception on the iterator (port vs message
in sequence), besides Ardour's mixer-strip is preferably used
with a single MIDI port. Most plugin-standards also only support
one port.
If need be LuaDSP run_map() can be used to handle multiple
MIDI I/O ports already.
The previous approach failed in case where PluginInsert
uses no-inplace buffers with a linear map.
Since buffers are replicated up to a total of number of
all (inputs + outputs), the number of output buffers
could not be determined. There was insufficient information
using the I/O map alone.
With a known number of outputs processing and applying
the i/o map is also a lot easier and faster.
This break the API of process_map().
Since Lua function arguments are not typed, there is no
explicit "const", and a function can always modify the parameter.
When passing `ChanMapping const&` as argument, the object is
copy constructed. In this specific case the std::map<> members
of ChanMapping allocate memory.
Passing a pointer to the object works around this issue.
LuaBridge later dereferences the object as needed when calling
c++ methods, and copy-construction would only happen later.
Empirically this decreases gc-spike duration (worst-case) by a factor of
two and speeds up the average gc-run by a factor of over 4 (depending
on the amount of memory used by the plugin).
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Robin Gareus
Paul Davis
luz paz
R
Tim Mayberry