Bundle all serialization function with the structs whenever possible to
simplify the serialization function, and add `Foo::Response` types so we
can make the `passthrough_event()` function slightly more type safe.
This could prevent resizeable plugins from being resizeable in Ardour if
the initialized timestamp just happened to be greater than the current
time, since the returned result would then likely be some invalid value.
String constants will be converted to `std::string` because it's not
constexpr yet, and that will allocate for longer strings. Since this
function only prints something when `YABRIDGE_DEBUG_LEVEL` is set to 2
or higher that seems like a waste.
Should be equivalent. The only reason why we use container2b in some
places is because strings based on `Steinberg::char16` arrays will have
an incorrect length on the Wine side, because character traits for
`wchar_t` is still reflects Linux instead of Windows there.
This basically changes the default small vectors during VST2 event
processing from 256 bytes to the size of a `DynamicVstEvents`
object (which also includes a small_vector to hold MIDI events without
allocating) and makes them thread local. We already have a similar
optimization for VST3. There it's a bit neater since we already had to
separate audio processing functions from non-time critical functions.
Here we don't have that separation, so we just made these buffers thread
local, large enough to hold our predefined number of events, and we then
just shrink them to fit if these buffers grow even more (which can only
happen after reading or writing chunk data).
The change doesn't specifically target `effProcessEvents()`, but that's
where you would see the differences. This is also relevant for
`audioMasterProcessEvents()`.
Apparently we also never did this for VST2 plugins, so this should be
safe. Filling the vectors with zeroes here had a non-negligible
performance impact according to perf.
I once read years ago somewhere on Stack Overflow that `std::vectors`
with that are preinitialized to a default size would allocate the
initial capacity on the stack. This of course doesn't make any
sense (run time sized stack allocations can cause all kinds of issues),
so we were still allocating with our default 64-byte sized buffers, but
just not as often.
C++ would always construct an `std::string` from the string constant
every iteration. Since this also happened when `YABRIDGE_DEBUG_LEVEL` is
not set to 2, this ended up causing unnecessary allocations.
Events, parameter changes, and the individual queues contained within
the parameter changes all use dynamic memory allocation. Preallocating
some memory for those things inside of the objects may prevent latency
spikes when they those objects are first filled. This is especially
useful for the parameter changes since there's no way to reserve memory
in a vector of vectors.
This prevents reinitializing `std::variant`s when the variant we want to
deserialize is already active. We store audio buffers in variants, so
reinitializing them results in a lot of unnecessary memory frees,
allocations and writes during every processing cycle.
I blindly assumed the original implementation also did this, but this
version `std::variant<Ts...>` objects from being reinitialized if we're
deserializing a variant that's also currently active in the object we're
deserializing into. For simple structs this won't make any difference,
but in yabridge we often use variants to differentiate between things
like single precision and double precision audio buffers. Those buffers
are allocated on the heap, so recreating the objects every time we
deserialize them adds a lot of unnecessary overhead.
We did a ton of work earlier to make sure we can reuse these objects,
but `auto` implies the type is never a reference type, and we were thus
unnecessarily creating copies every iteration, kind of defeating the
purpose of doing all of this in the first place. We could do some
template trickery here, but it's also safe to just make the persistent
object thread local since the actual objects aren't that large.
We don't need any special handling for this since our default argument
detection will handle strings, but it might be useful for log output if
a host ever uses this. At the moment there don't seem to be any hosts on
Linux that use this.
Robbert van der Helm