Age | Commit message (Collapse) | Author |
|
LV2 uses "enabled": -1: inactive, 0: bypassed, 1:enabled
VST3 has "bypass: 0:active, 1: bypassed
|
|
|
|
|
|
|
|
Previously this could assert(), copying a buffer to itself.
|
|
[Re]name sidechain port directly when a plugin is added.
Usually plugins are constructed without an Route (owner is unset).
PluginInsert c'tor may already create a side-chain port, at the
time of construction the sidechain port will be created using
the port-name "toBeRenamed".
Previously the plugin had to be added to a route using "add_processor",
in order to set a unique name, before a new plugin with sidechain
could be constructed.
ProcessorBox::use_plugins() did that in the correct sequence,
however there may have been cases where this didn't work, and
Route::add_processors() was called directly..
|
|
This allows to indicate that a control should by default be displayed
inline in the mixer-strip.
Previously that was hard-coded for and enabled for send-level
controls only.
|
|
|
|
When stopped start_sample == end_sample.
This fixes accidental automation lookup,
as well as plugin time/position information.
|
|
When looping, we do not want to resolve notes at the end of the loop via ::realtime_locate() -
::get_midi_playback() has already taken care of this. But when not looping, we need this. So,
add an argument to tell all interested parties whether the locate is for a loop end or not
|
|
This handles a very specific edge-case: A script that was
successfully parsed before, fails load on session state restore.
|
|
We determined several years that we should never ever do this,
and changed the basis for the free/demo copy because of that.
|
|
|
|
|
|
|
|
This tries to make it clear what the BufferSet limit semantics really are
|
|
|
|
|
|
This allows mono to stereo plugins to override the default
routing and forces both outputs to be connected.
|
|
|
|
This fixes a bug that can result in inconsistent session-state when
copying plugin state from one plugin to another (via drag/drop
ProcessorBox::object_drop, LINK).
The underlying plugin state and settings are copied, port _shadow_data
is updated, and ::get_parameter() shows the correct new value.
However the Controllable was not updated. On Session save/restore
the value may have be lost or was inconsistently restored.
|
|
|
|
|
|
|
|
This is relevant for some VST specifics (e.g connected pins) or
similar audioMasterCallbacks that use either global or plugin-insert
specific data.
|
|
|
|
e.g. Mixbus channelstrip should be hidden, also mixbus' built-in
effects are exposed as well-known controls
|
|
|
|
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.
|
|
At this point in time MIDI buffers are vastly over-sized.
They include VST and LV2 event structure. This added about a MB per
plugin for no benefit.
|
|
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.
|
|
Prefer std::map::at() over std::map::operator[] to allow const maps.
For debug builds, there should probably some try{} catch{} along with this.
|
|
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.
|
|
Automatable::add_control() already does insert a given parameter
to the _can_automate_list list if it's automatable.
|
|
|
|
|
|
|
|
* dedicated API for classes (effect, instrument, util)
* prepare for tags (rather than categories)
* prepare removal of per-plugin in_category() API
|
|
|
|
|
|
* 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
|