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.
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'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.
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.
We do this by using this new `MessageReference<T>` type to avoid copying
our `YaAudioProcessor::Process` struct and the contained `YaProcessData`
object. This is only part of the work, but this redesign lets us keep
the these objects alive on both the plugin and the host side. On the
plugin side, we'll simply serialize the data from the referred to object
without copying it. On the Wine side, we'll write the data to a
persistent thread local object, and then reassign the
`MessageReference<T>` to point to that object. This lets us serialize
'references', thus avoiding potentially expensive allocations. With
these last few changes alone VST3 plugins are already at the same
performance level as our optimized VST2 plugin groups.
This means that, we're now receiving into an existing `YaProcessData`
object, which should reduce the number of allocations on the Wine side
considerably. Next we should also reuse the `YaProcessDataResponse`
object.
It turns out we can't safely disable this, because in some situations we
still have these mutually recursive function calls. We could optimize
this a bit to have those calls be handled by the general sockets, but
this is much more manageable.
This reverts commit 415c1b5683.
This way every relevant object instance will get its own thread for
handling these calls. The alternative would be creating a full fat
Vst3MessageHandler pair for all object instances, but that would be a
huge waste.
We'll need this for handling `IAudioProcessor` method calls in VST3. We
basically want a `Vst3MessageHandler` per `IAudioProcessor` instance,
but without the additional socket spawning or extra thread.
This now takes a regular overloaded function and the visiting is done in
`receive_messages()` itself. This way we can use templates to ensure
that the return type is correct. Otherwise auto will cause issues in the
future when we want to return multiple concrete types from a function
that takes a single variant. The alternative would be both receiving a
variant as a parameter and then returning another variant as a result,
but that is much less type safe.
- Now allows direct deserialization into existing objects. This will be
necessary for our VST3 implementations since the interface instances
we'll deserialize into will not be trivially constructable because
they have to be able to do callbacks.
- `ControlResponse` and `CallbackResponse` were dropped. These response
enums are not necessary because of the `T::Response` associated type
and returning the types directly makes the direct deserialization
possible.
Robbert van der Helm