In the old implementation, because pushSample() could be called on the
audio thread, and updated the levels array and the nextSample value
non-atomically, other threads (e.g. the UI thread) were not guaranteed
to see these updates in a consistent order.
This commit uses the same logic for the Bluetooth pairing window that we
use for JUCE dialogues and raises its level to NSFloatingWindowLevel
when there are always on top windows.
Previously, the AudioProcessorPlayer would attempt to find a supported
layout that matched the audio device's output channel count, and would
force the processor to use the audio device's i/o channel counts if no
better and compatible alternative could be found.
This change allows the AudioProcessor to retain its current i/o
configuration if no better alternative can be found. This may lead to
the AudioProcessor having different numbers of inputs and outputs to the
audio device.
If there's only one audio device input, this will be copied to all of
the AudioProcessor's inputs. Otherwise, each audio device input channel
will be copied to the corresponding AudioProcessor input channel. If
there are more device inputs than AudioProcessor inputs, then some
device inputs will be discarded. AudioProcessor inputs without a
corresponding device input will be cleared/silenced.
Similar rules apply to the output channels. If there are more device
outputs than AudioProcessor outputs, then device outputs without a
corresponding AudioProcessor output will be cleared. If there are more
AudioProcessor outputs than device outputs, some AudioProcessor outputs
will be discarded.
This change improves the initialiseIoBuffers function so that it can
handle the situation where the number of processor outputs does not
match the number of system outputs, and/or when the number of system
inputs is not 0, 1, or equal to the number of processor inputs.
The bug presented when selecting none for either input or output, when
the opposite input or output was a device that had the same name for
both the input and output
