If the block size changes from block to block, then it's possible for
inputBuffer to be smaller than buffer, but for buffer to be smaller than
the initially-allocated size of inputBuffer.
When plugins change their 'parameter info' this often means that their
previous parameter text is no longer valid, so we should fetch new text
to represent the parameter value.
This change was primarily tested with Kontakt.
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.
Previously, right-clicking on a slider could change its value, but the
parameter value would not be changed, leaving the slider in a different
state to the parameter.
When opening the "settings" menu of Arturia Pigments VST2, the editor
window would move itself over the JUCE non-native titlebar in the
AudioPluginHost. Then, when the editor was moved back into the correct
location, the titlebar would not be redrawn, leaving it in an incorrect
state.
This change forces a repaint of the editor's peer whenever the size
changes, forcing the titlebar to repaint after the editor has moved.
Native Instrument VST3s (I tested Kontakt and Supercharger) crash when
the bundleEntry function is called from a background thread on macOS.
This change disables scanning for VST3 plugins on a background thread
using the PluginListComponent, to allow loading these plugins in the
AudioPluginHost.
I can't find any "official" word on whether the bundleEntry and
bundleExit functions should be guaranteed to be made from the main
thread. However, the VST3PluginTestHost app seems to call these
functions exclusively from the main thread.
This fixes an issue with NI Raum and Choral where the editors would open
in a new window, rather than in the same window as the VST
AudioProcessorEditor.
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.
On macOS 10.15, stdatomic.h (included by the VST3 SDK) defines a macro
named atomic_thread_fence when building in C++20 mode. This macro was
trampling over a call to std::atomic_thread_fence from the C++ atomic
header, made in juce_Atomic.h.
No JUCE implementation files use the C11 atomic functions, so I think
it's safe to just undef the problematic symbol after including all the
VST3 implementation files.
Previously, on hi res displays, "Plogue AlterEgo" was opening with a
window that was too large, because the window size was applied before
the scale factor was known. When the scale factor was updated, the
window size was not changed if the window was hidden, so the window
would remain too large when it was shown.
Some plugins (e.g. FabFilter Pro-C 2) will reopen their windows at their
previous size, but without accounting for a new scale factor. For these
plugins, we need to explicitly set a scale factor of 1 before calling
getSize for the first time, in order to ensure that the plugin knows it
should return its desired unscaled size, and not its size at the scale
factor it was using last.
Other plugins (Surge) misreport their desired size when it is requested
before the window has become visible. For these plugins, we need to
re-request the plugin's desired window size after it has opened.
The problems above are mostly noticeable when opening/reopening plugins
on a hi-DPI display on Windows.
This fixes some issues with Izotope Ozone 9:
- Resizing would stutter, and could leave the view in an inconsistent
state.
- Closing and reopening the view after resizing would display black bars
around the editor view.
The root of the problem was that the call to Component::setSize() inside
the resizeView call checked whether the plugin supported resizing. If
not, it would force the embedded view back to the current size. This
behaviour is incorrect - if the plugin requests a resize via resizeView,
the new size should be applied whether or not the plugin "supports
resizing".
reuk
Tom Poole
ed
attila