The following was observed for a VST3 plugin hosted in Live 11.1 with
auto-scaling disabled:
- It never calls setContentScaleFactor on the plugin's UI, so the
wrapper has to check the current display on a timer and update the
current scale factor when necessary.
- It calls canResize on the plugin view after opening it, but doesn't
seem to respect the result of this call. According to the VST3
documentation, a host is supposed to only call checkSizeConstraint
during a live resize operation (which should only happen if the plugin
reports it can resize), but Live calls this function every time the
user drags the editor. It also passes the result of this function to
onSize, whether or not checkSizeConstraints reported success.
- When dragging an editor between displays, Live will continue to call
checkSizeConstraint and onSize with the editor’s old size in physical
pixels. In some cases, JUCE's "scale factor check" timer callback
fires, resizes the view to the correct size, and then Live
asynchronously calls onSize again with the editor's old size in
physical pixels, resulting in the editor being set to the wrong
logical size.
This patch ensures that checkSizeConstraint always returns the current
size of a nonResizable editor. This means that the logical size of the
editor should not change when the result of checkSizeContraint is used
to resize the window.
The host is guaranteed to re-scan all parameter values after setting a
new state on the plugin, so there's no need to notify the host about
parameter changes that happen during the setState call.
This also avoids a problem where Bitwig would complain about invalid
parameter IDs in 'engine.log' when loading projects containing JUCE
VST3s. These log messages were produced because a call to setState was
made before Bitwig registered the plugin's parameters, and the setState
call in turn called performEdit with parameter IDs that were yet to be
registered.
With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.
Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings
Known issues:
- Direct2D rendering is still not supported when building with MinGW due
to ABI compatibilities.
This fixes a bug where selecting "Always on top" in the plugin editor
window in Cubase 11 on Windows 11 on a display with > 100% scale would
cause the editor to display with the wrong scale factor.
It seems that Cubase calls removed() then attached() on the plugin view,
destroying and recreating the editor wrapper component. The editor
opened with 100% scale, but requests from the host to set the "real"
scale factor were ignored because the JUCE wrapper thought that the
requested scale had already been applied.
Applying the cached scale factor directly after constructing the editor
keeps everything in a consistent state, and seems to resolve the issue.
This change allows mouse events (including enter and exit events) to
reach unfocused views on macOS. This matches the behaviour of unfocused
windows on Linux and Windows, where components paint in their "hovered"
states even when the application window is in the background.
As a byproduct of using tracking areas on macOS, we can remove the fake
mouse move generator.
Hosts such as REAPER normalise the program parameter value by dividing
the program value by the step count, rather than going via the
parameter's toNormalized function. To be compatible, we should use the
same scaling technique. At time of writing, the coversion process is
detailed under the heading "Conversion of normalized values" on this
page:
https://developer.steinberg.help/display/VST/Parameters+and+Automation
Adds a mechanism to notify the host that the plugin state needs saving,
using updateHostDisplay.
Also allows JUCE hosts to detect when a plugin needs its state saving
via the AudioProcessorListener.
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.
