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`!
Setting up VST3 plugins without yabridgectl is a lot of work and quite
error prone, so it seems like a good idea to now modify the CI build
artifacts to merge the yabridgectl binary in with the regular archives.
Those also resolves#67.
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 can absolutely destroy performance when using VST3 plugins. REAPER
also does something similar with bus information from the audio
thread (for which we had to build in a caching layer), but with these
plugin bridges a VST3 plugin will quickly use ten times as much CPU time
as it should be using.
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.
Robbert van der Helm