The VST3 version of Voxengo TEOTE would deadlock in Ardour when Ardour
calls `IEditController::setState()`, the plugin calls
`IUnitHandler::notifyProgramListChange()` in response, and then when
Ardour calls `IUnitInfo::getProgramName()` while handling that callback.
All of these functions have to be called from the same thread in Voxengo
plugins.
We would never try to shut the group host down if nothing ever tried to
connect to it. This could happen when the native host gets killed after
initializing the yabridge plugin but before it gets the chance to
request the group host process to host a plugin.
This means we only have to compile everything two times, instead of four
times. We sadly still need to compile lots of files at least three
times. (once for native, once for 64-bit Wine, and once for 32-bit Wine)
Those DAWs would immediately call `IEditController::performEdit()` with
the same parameter change the plugin has just announced, which would
result in a deadlock. Hopefully this helps with #100.
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.
This works around a bug in the VST3 version of W. A. Production
Imperfect as mentioned in #97. Even if it's a synth and numInputs is 0,
the plugin will still try to read the input arrangement.
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.
I don't know how I've never noticed this, but we should of course only
be handling `audioMasterGetTime()` this way. This also explains why
enabling this permanently in the past broke some plugins.
We did this before implementing the deferred close in yabridge 3.0.0. It
didn't seem necessary anymore so we got rid of it, but without this
closing an iZotope Rx plugin's editor in Renoise was guaranteed to
trigger an X11 error and crash Renoise. Doing this reparent doesn't seem
to cause any slowdown but it does at least fix the specific combination
of iZotope Rx and Renoise.
The `LoadLibrary()` call for PSPaudioware InfiniStrip would fail because
the plugin would always expect COM to be initialized. Now if loading a
VST2 or VST3 module fails, we'll initialize COM and try again before
throwing an error. This may fix#94.
Plugsound Free by UVI will pass random garbage to the data parameter for
this function call for whatever reason, and we'll run into a memory
error if we try to read it. Mentioned in #93.
This fixes Native Instrument's FM7 crashing on MIDI input. The plugin
expects the last received MIDI event to always be alive during audio
processing, even if there have not been any new events in this
processing cycle.
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`!
We would close the socket, but the `receive_multi()` call would finish
after the object had already been deallocated using `erase()`. Somehow
this never caused any issues though.
Robbert van der Helm