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.
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.
It sort of goes against yabridge's principles to not do these
unnecessary `audioMasterGetTime()` calls if the plugin does that, but it
also hurts the user experience to not have this as a default.
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.
I haven't seen this cause issues myself, but it would not surprise me if
a plugin that produces a constant stream of FIXMEs would steal resources
from audio processing if the threads that are relaying those messages
are set to SCHED_FIFO.
We'll periodically copy the scheduling priorities from the host's audio
threads to the Wine plugin host's audio threads. The overhead of doing
this is about 1 microsecond on my system, so doing this every cycle
really adds up. But getting the Unix epoch time and comparing some
timestamps has a neglegible overhead, so this should give you the best
of both worlds.
Next we'll do the same thing for VST3 plugins.
As suggested by @jhernberg
This is a breaking change. Old projects containing VST3 plugins running
through yabridge will no longer work without modifications. I'll write
some scripts to convert the class IDs stored in those project files soon
a migration path.
The UIDs reported by the plugin were apparently wrong, which meant that
the native Linux VST3 version of plugin X and the normal Windows VST3
version of plugin X used different class ideas than the Windows VST3
version of plugin X running through yabridge. Those things are supposed
to be compatible, so we sadly needed to make this change at some point.
This got removed in 74dc8225d1 when I
wanted to rework all `*Impl` classes the same way I did with
`YaPluginFactoryImpl`. This ended up not being possible, but
accidentally also removed this forward declaration. With unity builds
this did not cause issues however, but with regular builds it might
depending on which files are changed.
This prevents REAPER from crashing when removing the last instance of a
plugin and then readding it. REAPER doesn't unload the module even after
it removes its last plugin factory instance. This means that before this
the plugin factory would be freed but we still had a seemingly valid
pointer to it that we would try to access.
By directly stopping the IO context there was a chance that a task would
get cancelled outright if all stars aligned in the wrong way. Stopping
the IO context could happen between posting the task to the context and
waiting for it. This approach is much safer as we cannot drop any work
this way.
This would cause crashes in Bitwig, as `RunLoopTasks`' destructor would
not be run after the event handler has been unregistered, and we
unregister the event handler in that destructor.
Robbert van der Helm