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.
Some plugins return 0 from effGetVstVersion and are hence not detected
as instruments. e.g. VeeSeeVSTRack (VCV). This may also explain why MIDI
port of some other VSTs are not exposed.
Most VST2.4 return 2400, so checking [effGetVstVersion] >=2 (and not 2000)
was incorrect to begin with.
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.
This is required by 7d8b93ad for showing error when actively recording.
It also prevents other UIs (OSC, Lua,..) to change re-configuring
sidechain ports/plugins while recording.
A "fall through" comment is most portable way to indicate
"no break, fallthru" cases.
* __attribute__ ((fallthrough)) // is not portable
* [[fallthrough]]; // is C++17
lili93's session (#ardour) triggered this w/jackd 512fpp:
Drag/Drop copy a latent plugin from one track to another while rolling.
The GUI-thread as well as the auto-connect thread concurrently call
jack_recompute_total_latencies(). The auto-connect thread holds
a process lock while doing so. The GUI does not use any mutexes.
This randomly deadlocks in libjack.
backtrace: https://pastebin.com/6m3KGhWS
This is more of a workaround than a fix. Simply by forcing the
URI to be sortable (VST-user presets are sorted at the end).
This eventually needs a deeper cleanup and API consolidation
PluginInfo::get_presets(bool) returns an ordered std::vector.
However this API is only used in a few cases where the plugin is
not instantiated. PluginInfo::get_presets(bool).
The problem is Plugin::get_presets(). The method returns
information that was previously cached by Plugin::find_presets() in
std::map<URI, ...>
Ardour's VST MIDI buffer API does not yet implement offsets and limits.
When a cycle is split, the same midi-buffer is used for all sub-divisions
leading to duplicate, offset, events.
