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`.
When building a static library, VS2019 replaces the generated link pdb file with the one created during compilation due to a broken copy step in Microsoft.CppCommon.targets. This workaround generates the pdb in the output directory so the copy step is skipped.
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.
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.
Tom Poole
reuk
ed