Arch tries to build yabridge against this version, and some things are
now broken. We need to more forcefully hack tomlplusplus into thinking
its running on Linux, and shared library mode also needs to be
explicitly disabled.
With the `ghc::filesystem` dependency from the previous commit. If we
can replace the rest of the Boost.Filesystem dependency then we can get
rid the one nasty runtime dependency we have, and it will make
implementing the chainloading simpler since can reuse more code without
bringing in Boost.
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.
Apparently this can actually make a difference in some cases, and the
C++ Core Guideliens recommend doing this on all default constructors,
destructors, and all functions that can not throw (and thus also don't
allocate).
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.
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 also changes the refresh rate for most plugins. You can now lower
this setting if your computer is struggling to keep up with rendering a
certain heavy plugin.
This is not ideal since it requires the user to know about this option
and to create a config file, but I think it's the best we can do without
compromising on yabridge's transparency and 'zero hacks' philosophy.
See #29 and #32.
Robbert van der Helm