The previous implementation could emit 'wildcard' channel layouts in too
many scenarios.
A wildcard channel count is -1 or -2, and indicates that any number of
channels is supported on the bus.
If the input and output layouts must match, then a layout of [-1, -1]
should be returned.
If any layout is valid in both directions, then a layout of [-1, -2]
should be returned.
In the case where we have a bus A and opposite bus B, we will now only
emit a wildcard count for bus A if every bus standard bus layout up to a
channel count of 16 can be applied successfully without changing the bus
count of B.
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.
