This is very ugly so hopefully I can think of a neater way, but now the
response object is just a set of pointers, so we can avoid all copies
and moves on the Wine side.
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.
VST3 plugins could freeze in REAPER when the plugin sends
`IComponentHandler::performEdit()` followed by
`IPlugFrame::resizeView()` when REAPER simultaneously tries to call
`*::getState()`. Here `*::getState()` gets called from the GUI thread,
while `IPlugFrame::resizeView()` has to be handled on REAPER's GUI
thread, resulting in a deadlock unless we use the plugin-side mutual
recursion mechanism.
I've seen this cause issues with PSPaudioware InfiniStrip.
When setting the state on the audio processor, it can happen that plugin
triggers a resize from the edit controller. We should also be able to
handle that situation.
With this we should be able to handle `setState()`s that try to resize
the currently open editor. This could pop up when using the preset
browser in REAPER with plugins that recall their old size when loading a
preset.
This greatly improves compatibility with VST3 plugins in Ardour and
Mixbus. Most notably the FabFilter plugins would previously freeze when
having the GUI open while duplicating or inserting new instances.
Since the restart will always be called from another thread, and when a
plugin asks for a restart during initialization this can quickly lead to
issues.
This is in some cases needed to get decent performance in REAPER, as
REAPER seems to query this information (which cannot change without the
plugin requesting a restart) four times per second.
This works around an issue with REAPER. During every processing cycle
REAPER would query how many input and output busses we have, and it
would then enumerate over all of those busses. This meant that if a VST3
plugin has 32 output busses, then REAPER will do 34 extra function calls
before processing audio.
Robbert van der Helm