Wine Staging 6.11 seemed to work fine for a bit, but somehow even more
software is broken than in 6.10. And the crashes are not even
deterministic anymore.
Timeouts haven't been a thing for over a year since yabridge checks
whether the Wine process has started successfully during initialization,
and the other issues should also not occur during normal usage with
yabridgectl.
This should make the troubleshooting section a bit easier to read
through.
Or, well, a more general environment setup section, but more tailored to
fsync since you haven't had to modify your search path during normal
usage since yabridge 2.1.0.
Depending on your system threadirqs on their own may not be enough, and
you actually need to make sure that your sound card's interrupt get
higher priority than other devices triggering interrupts.
Apparently you can tell udisks2 which options are safe to be used by a
user. More recent versions of udisks2 include the udf unhide option by
default. This closes#102.
For some reason ujam plugins (and other plugins made with the Gorilla
Engine, like the LoopCloud plugins) will throw a `JS_EXEC_FAILED` error
when trying to load the plugin while either of the STDOUT or STDERR
streams is pointing to a pipe. Simply redirecting the output to a file
fixes this. By default we'll write the output to
`<temporary_directory>/yabridge-plugin-output.log`, but you can also set
the new `disable_pipes` option to `"/dev/null"` to completely throw away
all output.
This addresses #47.
This was removed in 4a92034620 after the
VST2 callback prefetching from yabridge 3.2.0. Now with the recent VST3
optimizations, VST3 plugins always outperform VST2 plugins on my system
even when using plugin groups for the VST2 version (and not having to
use plugin groups is of course another good reason to prefer VST3).
At least for performance reasons, since with the changes in yabridge
3.2.0 they VST2 plugins perform as good or better depending on the
plugin groups settings. Using plugin groups is still less preferable
than using the VST3 version of course.
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.
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.
This would cause 32-bit VST3 plugins to crash in mysterious ways. What
ended up being the issue is that the plugins expected doubles to be
8-byte aligned in structs, while GCC doesn't do that by default in x86
code for legacy ABI compatibility reasons. Figuring out what exactly was
the issue took months, but luckily the fix was to just add an
`-malign-double`!
Robbert van der Helm