When passing in valid data with zero size, replaceWith() will do nothing and leave the MemoryBlock in its previous state which may be unexpected. replaceAll() will reset the MemoryBlock and resize it to 0
The plugin should interpret the arguments as VstSpeakerArrangement**
instances. It should modify the pointed-to VstSpeakerArrangement* so
that it points to a long-lived VstSpeakerArrangement in the plugin.
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.
This fixes a regression introduced by
6e9261ea66 which meant that components
were not given a chance to respond to shortcut keypresses if those same
keypresses were registered for a menu item. This resulted in behaviour
where shortcuts such as 'cmd+c' would not be passed to a focused
TextEditor if a different command with the same shortcut was registered
in the main menu.
With this change in place, we now check whether the menu item's shortcut
keys match the current event's pressed keys. If the keypresses match, we
can assume that the event was triggered by the keyboard, and dispatch
the keypresses to the ComponentPeer. If the keypresses do not match,
then the menu item was likely selected using space/return, or by
clicking, in which case the event is dispatched directly to the
ApplicationCommandManager.
This mostly reverts commit 6e89e61b89.
MIDI FX plugins are allowed to have audio channels, even if they only
produce silence. If a plugin requests a particular bus/channel layout,
the host should respect this request, or attempt to update the layout.
The host should fill all channels that the plugin expects to be filled.
The old commit also meant that we weren't correctly supplying the host
sample rate to MIDI FX plugins.
MIDI FX AudioUnits can retrieve their current sample rate from an output
bus. However, it's reasonable for a JUCE MIDI FX plugin to require 0
output buses, in which case the correct sample rate cannot be retrieved.
This patch modifies the AU wrapper to ensure that MIDI FX plugins will
always have at least one output bus. This bus does not necessarily
correspond to a matching bus in the AudioProcessor, and it will not be
passed to AudioProcessor::processBlock. With the output bus in place,
the correct sample rate is reported in `prepareToPlay`.
This resolves a regression which was introduced in
74ca3b44c4.
Prior to that commit, drag and drop on Linux/X11 worked as expected.
DragAndDropContainer::performExternalDragDropOfFiles allowed dropping
files onto other applications.
After the faulty commit, this function may cause the window manager to
enter a bad state in which the drag operation never finishes, making it
impossible to switch between windows or close windows.
I think the issue happens because the DnD source may receive (spurious?)
XdndLeave messages during the drag, which cause the peer's entry in the
dragAndDropStateMap to be removed. Before the faulty commit, each peer
had its own drag and drop state object, which was not destroyed in this
way.
This change will keep the peer's drag state object alive, even when an
XdndLeave message is received. The entry will still be removed when the
peer's window is destroyed.
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.
