Previously "zero custom/user latency" meant "default plugin latency".
This is now saved in a separate boolean allowing a user to reduce a
processor's latency to zero.
This also prepares for a global switch to use zero latency throughout
the whole session.
Keep a dedicated list of automated parameters to evaluate in realtime.
This fixes a performance issue with plugins that have many controls
with only few of them being automated.
These processors don't have a UI, so their load stats are not easily
visible. The stats can still be queried via Lua API or DSP-load
overview window, so we retain this for debug builds.
While gnu-gcc had `std::map:at const` as non-standard extension
it is n/a for older gcc on OSX.
Surprisingly this const& p() const; performs a tad better as well, likely
due to different exception handling.
Perhaps it is also worth investigating boost::flat_map<> as replacement
for std::map<>, here. Our common case is just a single entry, so using
a std::vector emulated mapping might help.
Another micro-optmization shaving off some ten microseconds for every
plugin. Also copying maps isn't RT-safe.
This may however cause issue if const map references can change
while a plugin is running.
For plugins with 10000 Control Inputs, dynamic_pointer_cast<> overhead
is significant, here ~2msec (~0.2usec per cast, optimized build, i7-5600U,
2.60GHz)
When a route with a sidechain is created from a template or by route
duplication the number of ports of the sidechain are set according to the
XMLNode defining the sidechain. Then the names are set according to the name of
the newly created route.
Thus all the pin connections defined in the template are replicated in the
newly created route.
When a PluginInsert is created it does not have an owner right away. That's why
a we need to set the sidechains name once the owner is known, in order to
include owner's name into the name.
Furthermore we need to follow renames of the owner.
VCVRack VST currently exposes 9999 automatable-control parmaters.
This slows down various GUI dropdown lists and dialogs.
(even worse: those parameters are not mapped to anything by default).
This change allows to limit automatable parameters to a reasonable number,
without loosing state of already automated parameters in existing sessions.
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
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
Rule #89: The *owner* of each automation-control is responsible to
evaluate automation of automated automation-controls (and emit Changed()
signals to notify the GUI and slaved controls).
This can happen during run(), when the Processor evaluates automation
(eg. PluginInsert does that), but needs to regardless, every cycle.
Emit Changed signal for GainControl
This follow the same concept as PluginInsert: The Changed signal
is called on demand when evaluating automation.
Caused by thinko when merging/replacing two conditional clauses in the
string-convert changes which resulted in bindings not being restored and
regeneration of id's in XML.
VST's effSetBypass may fail even though a plugin CanDo "bypass",
and it can be case-by-case (depending on plugin-settings).
This codepath is not yet active, pending testing.
This mechanism re-uses internal abstraction (plugin-enable).
Other plugin-specs designate a control-port, for VST we 'emulate'
a control-port.
There is still debug-output to stderr, here while testing.
