Previously, updating the program or bypass parameter could cause an
out-of-bounds access into the parameter value cache. This is because
AudioProcessorParameter::getParameterIndex() was used to index into the
cache, but the parameter index could be negative for parameters that
had not been added to the AudioProcessor.
We now use the appropriate index in the cache for parameters that
have not been added to the AudioProcessor.
To use this feature, derive your AudioProcessor from
VST3ClientExtensions and override getPluginHasMainInput() to return
false. The main input bus will then be designated as an Aux bus, rather
than a Main bus.
This is mainly useful for synth plugins like vocoders, which may need a
sidechain audio input, but which should replace all audio on the channel
with the output of the synth, rather than mixing with the audio input.
In cases where a VST3 plugin set a non-zero latency in its
prepareToPlay, and then set its latency to 0 later on, the host was not
notified about the latency change.
In older versions of the VST3SDK, hostContext is a raw pointer,
in newer versions it's a smart pointer. If we do manual
refcounting with the smart pointer, we may cause leaks.
Previously, IEditController parameter indices were being used to index
into the AudioProcessor parameter array, but these parameter indices are
not guaranteed to point to the same parameter (parameter groups may
cause reordering on JUCE's side). Now, we use the IEditController
indices universally.
Audition incorrectly increments the ref-count of the IPlugView* returned from IEditController::createView() and never fully releases it. This commit reverts e0306d25 for Audition to ensure that an editor is always returned, otherwise Audition displays a blank GUI.
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.
Live calls getSize() before the plug-in has been attached to the system window and can query the correct system scale factor, this size is then used to resize the plug-in after it has been attached resulting in an unscaled window size.