Some plugins, such as the 'AGain' demo from the VST3 SDK and Diginoiz
Subdivine segfault when setParamNormalized is called from a background
thread.
This patch attempts to ensure that calls to get/set parameter values can
be made safely from the audio or message threads.
It also adds some MessageManagerLocks around some other calls to the
EditController's member functions which should technically only be made
from the GUI thread.
Finally, it updates the parameter input queues to the IAudioProcessor so
that writing to the queue is wait-free. As part of this change, a new
queue type is introduced which holds up to a single point. This should
improve memory usage for plugins with many parameters.
Previously, all VST3 parameter changes were signalled to the host via
performEdit, regardless of the originating thread. This breaks the
contract of the IEditController interface, which requires that all calls
are made from the UI thread.
This change modifies the VST3 wrapper so that it will only call
performEdit when a parameter is set on the message thread. If a
parameter is set on the audio thread instead, then the parameter change
will be signalled to the host using
`ProcessData::outputParameterChanges`.
If your VST3 plugin uses a background thread to update parameters for
some reason, you'll encounter data races. Please don't do that.
When loading a JUCE plugin in Live, Live was producing diagnostic
messages in its Log.txt warning that restartComponent was being called
from a non-UI thread. This change should silence this warning, and
improve compliance with the VST3 spec.
IFileDialog::Show and CoUninitialize both seem to require the main
message loop to be active and running when they are called. If we block
the message thread while calling these functions, we may cause a
deadlock.
The destructor of the Win32NativeFileChooser was blocking the message
thread until the background thread exited, but the background thread was
unable to make progress while the message thread was blocked.
To work around this issue, we now pump the message thread in the
destructor of the Win32NativeFileChooser. If a dialog is currently
active, this should allow it to exit gracefully.
Note that we cannot use MessageManager::runDispatchLoopUntil here:
- MessageManager::runDispatchLoopUntil will not process any messages if
the quit message has been received, which could lead to deadlocks if the
FileChooser is destroyed after the quit message has been posted.
- This function isn't defined when JUCE_MODAL_LOOPS_PERMITTED is disabled.
When immediately closing a MidiInput after starting, the ALSA handle may be closed whilst the MidiInputThread is running and it polls a destroyed handle
