CLAP will use a similar structure. Alternatively we could use
namespaces, but while that would solve clashes for the linker with the
way namespaces in C++ work it would still be ambiguous which one is
being referred to just looking at the code.
A user reported that REAPER was using these on the REAPER forum, but I
have not been able to reproduce that. And they went MIA after posting
about it. But hopefully this helps.
We need to silence the warning about this because Steinberg doesn't
declare their base class destructors as virtual (because of Windows ABI
compatibility issues). But we can still do it inside of yabridge to have
at least a bit more safety.
We had to add an even hackier hack now to get Boost.Process to
interoperate with Asio's IO contexts. This will be replaced later when
we replace Boost.Process.
With the `ghc::filesystem` dependency from the previous commit. If we
can replace the rest of the Boost.Filesystem dependency then we can get
rid the one nasty runtime dependency we have, and it will make
implementing the chainloading simpler since can reuse more code without
bringing in Boost.
I noticed that there were some realtime adhoc-acceptors running on my
system. That should of course not happen, since these only exist to
catch some sporadic (and likely as a result of a badly behaving plugin)
mutual recursion on the audio thread.
I'm not a fan of Hungarian notation, but C++ kind of needs it with its
implicit `this`. And of all the common options for this, I find
suffixing members with an underscore the least offensive one.
We now use shared memory to store the input and output audio buffers.
This means that we have to copy less data every processing cycle, since
a single copy to and a single copy from the shared memory object
suffices now. This should reduce the DSP load for VST2
plugins (especially when used in a plugin group) marginally to
significantly depending on the plugins used and the system
configuration.
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()`.
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.
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.
This does what we did for a few functions in the last few commits for
every function. We now use either the `std::invocable` concept or our
own `invocable_returning` concept wherever possible to make sure we pass
function types to these template functions, since constraint errors are
a lot more readable than template deduction errors. And instead of
having to specify the return type as a template argument, we now just
use `std::invoke_result_t<F>` instead. The VST3 message handling
functions are still using the good old `typename F` since those are
overloaded polymorphic functions. This was also a good moment to modify
`AdHocSocketHandler::send()` to allow functions returning void (this got
rid of an old fixme where we had to return some dummy value from a
function instead of just not returning anything).
Apparently this can actually make a difference in some cases, and the
C++ Core Guideliens recommend doing this on all default constructors,
destructors, and all functions that can not throw (and thus also don't
allocate).
Making these thread local statics makes much more sense for their
purpose. The old approach technically wasn't thread safe (even if it was
never an issue) and this gets rid of a data structure.
Robbert van der Helm