Using same physical inputs in different buses

(JUCE newbie alert)
I’m writing a plugin host + the plugin itself. I need to use the same physical inputs in two buses. Each bus is delivered to a different plugin input, as shown. The user will use a preference dialog to select which physical input is used for the main input (in0) and which for the SC input (in1).


What is the best way to make those connections? When I add a bus, I can only request the channel arrangement but not the physical input… what is the relation between the bus arrangement and the physical input ordering?

Hi, am I not getting replies because this is not possible? That is a valid reply too…

Of course you can do that. The audio that should be sent to the plugin (“physical audio inputs”) come from somewhere - e.g. a callback from a device driver. They are likely in some sort of buffer(juce::dsp::AudioBlock<float>, juce::AudioBuffer<float>, etc), or at least a float** and int numChannels and int numSamples.
Likewise, the data to be sent to your plugin must be in some sort of buffer as well.

To get from your input buffer to the plugins input buffer, you could

  • Create a temporary buffer for each bus, copying the data into that buffer, depending on the users selection, then pass that buffer to the plugin.
  • Map the same channel pointer from your input buffers to different channels in the buffers, before passing them on to the plugin.

It totally dependes on your needs.
If you need more specific help, make your question a little more specific. Show a minimum working example or some pseudocode, then its much easier to actually help.

Thanks for this. However I’m missing some fundamental understanding on how to initially request the physical input. What command asks the device to send audio from, say, mic 3 and mic 7 into the bus I defined?

Your AudioProcessors don’t really have any straightforward way to query or manipulate that stuff, it’s more a responsibility of the host application itself, AudioDeviceManager and/or the AudioDeviceSelectorComponent. Your AudioProcessors just receive buffers of audio and there’s no direct link to what is going on with the audio hardware.

AudioProcessor exists mainly to implement plugins for use in 3rd party host applications and it hasn’t really been a part of the plugin APIs (like VST) to know about or manipulate things like the host’s hardware I/O.

However, if you are developing both the host and plugins for it at the same time, you can of course use some tricks to get access to the hardware/host data. Pass in some way a pointer or reference to the AudioDeviceManager of your host into your AudioProcessors, for example. Then you could potentially do stuff like get the physical input and output names in the AudioProcessor’s GUI etc.

As I wrote, I’m implementing the host + the plugin. It is the “use some tricks” part that I’m trying to avoid… I’m looking for “the JUCE way” to do it properly. I’m expecting to see something like this (oversimplified):
getAudio("Mic3", myBusToFill[0], numSamples);
getAudio("Mic7", myBusToFill[1], numSamples);

For example the names of the physical I/Os are not part of the plugin/AudioProcessor API. You have to use some non-standard way to get access to that information.

Actually I can read (and did read) the names from the device, so more accurately:
getAudio(physIn[3], myBusToFill[0], numSamples);
getAudio(physIn[7], myBusToFill[1], numSamples);

You can’t “get” audio from the hardware in the AudioProcessors, the host is supposed to call the processBlock with the audio buffer filled with the hardware’s input.

But I am writing the host…

Xenakios point is, that YOUR plugins cannot get the physical ports from YOUR host through the standard plugin API, because that is not what it was designed for.

The host will decide on its own discretion, what signals to send to the plugin. Your plugin has no say in that.

If you want to do that, you will have to write your own plugin API as well.
I think then you are at the point to just make it a standalone app feature. You can still add plugin hosting for other things though.

Let’s forget the plugin for now. Let’s say I’m only the host wanting to send out to the speakers both Mic3 (to the left) and Mic7 (to the right). I’m looking for a way to request those inputs.

You just open enough inputs in the host code and in the audio callback method route the audio how you like. For example, if you open the audio device with 8 inputs, the audio callback code has access to those 8 audio channels. You can then copy the audio into the desired output channels.

Oh I see… What are the relevant classes/calls, what do you mean by “open enough inputs”? Do I always have to give access to all the device inputs if I only need two at a time?

Does this mean that the device manager would need to always fill the callback buffers with the audio from all the inputs? Sounds like an overkill…

The easiest way is to open an AudioDeviceSelectorComponent

I think there’s a way to get only the active channels into the callback, but in practice one probably wouldn’t want to do that if the needed channels need to be changed dynamically when the audio is playing. It’s IMHO better to open all the potentially needed channels at once and deal with the routing in the callback/DSP code. (Custom code is needed anyway if there are things like mixing the channels involved.)

Thanks to both of you, I’ll take a look at it later on. Good weekend with good health.