CLAP allows mixed precision ports. For instance, the main IO ports can
be 32-bit only, while some CV ports allow 64-bit audio. The plugin only
knows the sample format it receives when the process call happens, so
we'll always need to allocate enough space for that to work.
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.
This avoids doing the duplicate check (since both `setProcessing()` and
`setActive()` would be called), and this also gets rid of the assumption
added a couple commits ago that `setupProcessing()` is only ever called
once, which is not true.
This fixes Waves V13 VST3 plugins crashing when opening the editor. They
will likely still crash later on anyways because they're kinda broken.
Amazing.
This wasn't implemented yet because no plugin tried using the interface
in this way before this, but Surge XT incorporates the host's context
menu items into their own (much more elaborate) context menu. To
accommodate this, we now copy over all of the host's prepopulated
context menu items to the Wine plugin host, and calling the targets
associated with any of those items will cause the target on the
associated context menu item on the host to be called.
This is slightly more complicated than what would otherwise be necessary
because Bitwig does not assign tags to their context menu items and
instead always uses 0.
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 accidentally reverted a little bit too much code in
762e622416. This didn't appear any sooner
because plugins are supposed to call `IPlugFrame::resizeView()` during
`IPlugView::attached()`, so this only affects plugins that don't confirm
to the spec.
This reverts commit ff76e482f2.
This was a workaround for a race condition in Nimble Kick when opening
the editor while the plugin has not yet been authorized (a Win32 timer
proc between `IEditController::createView()` and `IPlugView::attached()`
would cause a stack overflow because the plugin doesn't check if the
things it wants to use have actually been initialized yet).
But as it turns out, Bitwig Studio now calls
`IEditController::createView()` unconditionally when loading a VST3
plugin, regardless of whether the user wants to open the editor or not.
So this workaround would cause the message loop to be stalled
indefinitely until you open the editor. Since this would also cause
Nimble Kick to break in the Windows version of Bitwig, we'll simply
revert this workaround. If you need to activate the plugin on Linux, you
can load it in the Windows version of REAPER running under Wine instead.
After that the plugin will work just fine under yabridge.
This should in theory prevent Nimble Kick from triggering a stack
overflow when the event loop timer procs before `IPlugView::attached()`
gets called and the plugin hasn't been registered yet. I haven't seen
any other VST3 plugins trigger a race condition here.
This is super difficult to trigger on purpose, but I did run into it at
least once just now so it seems like a good idea to at least make sure
that this doesn't happen.
REAPER initializes the plugin's editor first before reparenting the
parent window to the FX window, so our `topmost_window` didn't actually
refer to the FX window.
This is needed as a workaround to support Waves VST3 plugins.
Right now does does not actually fix the issue because the arguments are
not updated in the subclasses. The next commit will fix this.
Seems weird to need this specifically so we can use the map overload
that creates a new instance when the key doesn't exist in the map. This
seems safer.
The sizes were wrong, and Blue Cat Audio's VST3 plugins seem to use the
upper bits to store the channel configuration, which thus got read out
incorrectly.
In the same way as 50c25c1cf0 did it for
VST2 plugins. Input and output audio data is now stored in a shared
memory buffer instead of being sent over the sockets. This reduces the
bridging overhead to a minimum since copying data was the most expensive
operation we were doing and we now only need to copy the entire buffer
once per processing cycle.
On the Wine side. Instead of always having it enabled and disabling it
when it could potentially hurt (i.e. when handling GUI related things),
we'll now only enable it when it's potentially beneficial. This way we
don't have to constantly switch scheduling policies on the GUI thread.
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).
Robbert van der Helm