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.
When setting the state on the audio processor, it can happen that plugin
triggers a resize from the edit controller. We should also be able to
handle that situation.
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.
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.
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.
I haven't seen this cause any issues this way, and I could imagine that
this could cause some hangs when initializing a second instance of a
plugin while you're interacting with the GUI of the first instance.
This reverts commit a495f1a67f.
This ended up not being an issue. What we _do_ have to do, sadly, is to
have a mutual recursion context stack per plugin. Otherwise multiple
plugin instances can deadlock eachother.
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.
Robbert van der Helm