I observed a deadlock when scanning AU plugins in-process in the
AudioPluginHost, and then clicking the "cancel" button in the scan
progress alert window.
The cause of the deadlock seems to be that JUCE uses async messages to
create and destroy AU plugins on the main thread. When running a plugin
scanner on a background thread, it was possible to end up in a situation
where the background thread was waiting on the message thread to process
a create/destroy message; and, at the same time, the main thread was
blocked waiting for all scan jobs to complete. This seemed to happen
because scanFinished() was called directly from the Scanner's
timerCallback as soon as the progress window was cancelled, even if
there was still a scan in progress at that point.
To avoid the deadlock, we now wait until the current scan has completely
finished before allowing the timerCallback to call scanFinished(). If no
scan is in progress, then the main thread can safely destroy the scanner
ThreadPool without needing to wait at that point.
The double-precision buffer is unnecessary because internal nodes should
be prepared using the same precision as the graph itself, and all
AudioProcessors *must* support single-precision processing. Therefore,
if the graph is prepared to use single-precision, then all inner nodes
*must* also use single-precision.
This change also shares the remaining temporary buffer.
There were a few "ambiguous operator new/delete" errors that were due to
inheriting from a private base class that used the leak detector. These
errors are resolved by adding the leak detector to the derived classes.
JUCE_API was missing from a few useful types, notably the ARA hosting
types.
Prior to this commit we used the integral version of localAreaToGlobal
before multiplying its result by the scale factor. This multiplied the
rounding error of localAreaToGlobal<int> by the scale factor. Now we
only round after all calculations have been carried out.
