Dynamic Multibus Plugins


#1

Hi @fabian,

I am working on a plugin with dynamic buses and Multibus API with named buses.
I really like the new Multibus API.
But it seems to me that changing the number of buses during runtime is not possible with bus names.

I can change the bus layout with

  • AudioProcessor::setBusesLayout, which applies my new BusesLayout, but without bus names, as it includes only AudioChannelSets
  • AudioProcessor::addBus, which also does not include bus names (removeBus of course is fine)

So it seems to me that bus names can only be included in the constructor - the only place where I can include BusesProperties - but not during runtime…

To solve it, I’d like to propose two changes:

  • add a new method AudioProcessor::setBusesProperties similar to setBusesLayout (and internally similar to initialise, just that buses need to be cleared before)
  • make AudioProcessor::createBus public - tried that and it works fine for me

What do you think? Or am I mislead?


#2

Yes it is, but it’s a passive: the host gives your plugin a callback and asks for the name of a newly created bus. See the canApplyBusCountChange callback. You’ll need to supply the bus name via the third parameter.


#3

I’ve recently posted an example on how to use this method to wrap another plug-in: 4.3.0 Some AU plugins have wrong I/O Count


#4

Hi Fabian,

thanks for these hints and for the quick reply!
Unfortunately priorities have changed and I could not try it out yet.
Will let you know once I tried, but probably after christmas time…

Wish you some nice and peaceful days!

Harald


#5

Hi @fabian,

thanks again for your hints.
I had the same conceptual problem trying to sync back to the host as @Nikolai in the other thread, where you clarified that “the plug-in is mostly at the mercy of the host when it comes to bus layouts”.
So I entirely reworked my stuff to “mercy of the host” and it works fine so far!

But: I still have an issue with the Bus names.
What I wanted is e.g. multiple playback buses and one recording bus.
(in fact I am working on a multi file player and recorder for the JUCE plugin host, which I could contribute to the project later, as discussed here).

One filter node is the recorder and one is the player (playing n files + playback of the recorder file).
So in the player I always wanted to give the last bus a name like “Rec…” if there is a recorder node.
So something like “Play1”, “Play2”, “Play3”, "Rec"
But the canApplyBusCountChange callback only gives me the last added bus.
If a bus is added, I cannot rename the second last, which is “Rec”.
So I would get something like “Play1”, “Play2”, “Play3”, “Rec”, “Play4”.

Removing the last bus to rename it seems not possible within canApplyBusCountChange as it would lead to a recursion.
As the Rec bus also can be removed (by removing that filter node), it is also not a solution to put it at the first place.
For now, I just enumerate all output buses… not too nice, but everything works so far.

Any idea on how to rename existing buses (within canApplyBusCountChange) or how to “insert” a new bus before the last one - or any other idea?
Thanks for any hint… maybe this could be of interest for other use cases also.


#6

Hmmm… I don’t think this is possible. I’ve modelled the multi-bus API closely around what plug-in formats support and what the majority of hosts allow you to do. The problem is that Cubase/Logic etc. do not probe bus names again when a bus is added or removed (apart from the bus being added).

Therefore, I could add this functionality to the API but hardly any DAWs would reflect this. I think this is just a limitation of DAWs at the moment.

I’ve been thinking about how to add playback+recording filter nodes to the ‘audio plugin host’. It’s probably easiest of you can only create the node when selecting the file you want to play or select the destination and format of the recording. This way, you know the format of the playback/recording nodes before you create them. This simplifies the implementations of these nodes.


#7

Thanks, that makes sense.
In my case, as it is only used within the JUCE plugin host, I could use a non-DAW-compliant solution.
Still it is of no interest to anyone else, so it might not make sense to invest any effort.

I did my solution with two nodes, one playback and one recording.
Only the playback has a UI and controls the recorder, which is a kind of slave node, connected with a SharedResourcePointer.

It already worked fine and I just reworked it for multibus now.
Will offer you the code for contribution soon. Some doc and cleanup is still needed.


#8

Hi, I finally published a first version of the audio plugin host extended with a multi file audio player and a recorder.
See new thread: https://forum.juce.com/t/audio-plugin-host-with-multi-file-audio-player-and-recorder