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 that makes it much clearer what we're actually doing. With old
`cache_time_info` was actually caching the response, but now we're
querying it before the plugin has even requested the information.
After a quick round of testing it seems like REAPER doesn't always
enable this on the audio thread, but Bitwig, Ardour, Carla and Renoise
do. So it should be safe to just get rid of the option and to leave this
enabled all the time.
This prevents Kush Audio REDDI from taking down the DAW when the host
passes it denormalized audio to process. I've discovered that the issue
with this plugin had to do with denormals in the issue linked below, but
I didn't realize that we can just enable the FTZ flag for plugins that
don't already do so.
https://github.com/osxmidi/LinVst/issues/174
This can be useful when plugins have (broken) host-specific behaviour
that you want to avoid. I'll later add a list of host/plugin
combinations where this may be useful to the readme.
- Don't call bp::search_path when using WINELOADER. It will return an
empty string for an absolute path.
- To match the behaviour of the exe wrapper scripts, only print the
wine version from WINELOADER if the path is executable.
Otherwise we would always use the 64-bit version and there would be no
way to use the 32-bit version, if version for some reason works better.
Relates to #80.
There is some sort of memory corruption going on and these plugins
usually segfault on the audio thread. I'm clueless as to what could be
causing this (I wouldn't be surprised if this is caused by an
interaction between the VST3 SDK and Wine's Windows.h implementation),
but it's probably best to disable loading 32-bit VST3 plugins completely
until this has been fixed.
Even though the interface ID is passed as an FIDString and there is a
function to compare FIDStrings obviously doesn't mean that you're
supposed to use them! Duh.
Robbert van der Helm