Multiple AudioAppComponents

Getting Started
6

The documentation definitively lacks educational documents to cover basic questions like:

  • What is a audio rendering pipeline?
    An audio rendering pipeline is a sequence of classes, that produce, mix or alter a continuous signal, i.e. sample arrays

  • What drives the rendering pipeline?
    There are two models for pipelines in general: push or pull. I.e. either a generator produces a signal and triggers the processing of the following processor (push). Or the audio driver pulls constantly blocks of samples out of the pipeline. The later one is how JUCE works.
    The AudioIODevice calls an AudioIODeviceCallback to pull samples. There are some implementations: AudioSourcePlayer, AudioProcessorPlayer, SoundPlayer and StandalonePluginHolder. You can add several callbacks to the AudioIODevice (calling AudioIODevice::start(AudioIODeviceCallback*) ), that’s why it worked for you to have several AudioAppComponents. But as @Xenakios wrote and you already figured out, that’s not how it is meant to be done…
    Pulling audio data usually happens in getNextAudioBlock() of AudioSources and it’s subclasses, and processing to alter audio data happens in AudioProcessor::processBlock().

  • What is an AudioAppComponent
    An AudioAppComponent is a convenience class to combine a GUI Component and an AudioSource. This way it is a good starting point, but most times you end up with your custom setup:

    • As AudioSource it has a getNextAudioBlock() to override, so you can feed your audio data.
    • Aggregating an AudioSourcePlayer, it is used to feed this audio into an AudioIODevice
    • To configure the AudioIODevice, it aggregates an AudioDeviceManager

  • Why is there no AudioIODevice in a plugin?
    A plugin is not meant to communicate to any hardware. Instead it adds it’s functionality to the host, so it gets fed data from and back to the host’s track. Any routing should be done inside the host. If the host doesn’t support specific routings, you are out of luck. There are sometimes workarounds, but usually they are hard to teach the users, so it’s fine for your in-house solutions, but not feasible for a commercial product.

Maybe one fine day there will be a wiki, where these kind of questions become accessible instead of ageing out of the forum…

11 Likes