RNBO Dynamic Routing / FX Chain

Oskarsh's icon

Hey first time poster here.

I am using RNBO and gen~ to create a FX Chain. I would like to create a effect where you can change the routing around. I have a patch with 4 Effects. Basically a FX chain like this:

Reverb -> Delay -> Distortion -> Bitcrusher

However I would like to create a dymamic more 'modular' fx chain where I can put the Reverb at the end and change the chain around in general.

Is there a way in RNBO to control the routing?

Any help is much appreciated, thanks in advance.

Jan M's icon

I cannot think of any simple dynamic routing system in RNBO (hopefully someone can prove me wrong.)
If you don't use more than 4 FXs you end up with 4! (=24) possible routing combinations. You could create an enum parameter with those 24 options to set the signal flow.

Oskarsh's icon

Thanks for your answer. Ideally I would have more effects than just 4 so it would pretty quickly blow up in scope.

Wil's icon

Can't you use a two matrix~ ?

I'm interested in testing this

Jan M's icon

Hi OSKARSH,

i agree, i was looking for a solution as well for a similar problem a while ago - for a project on a RaspberryPi. Unfortunately I couldn't find a really good solution, so I settled for fixed routing. But that decision also had to do with wanting to use a hardware interface to control the RasPi.

If you are targeting another platform there might be some possibilities, if you develop your own UI:

You can use the [inport] to send a list to RNBO where each list elements indicates the position of a certain FX in the chain. E:g. If you have

<reverb> (index 1)
<delay> (2)
<distortion> (3)
<bitcrusher> (4)

sending a list 4 2 3 1 would mean : <bitcrusher> --> <delay>- -> <distortion> --> <reverb>and you can set the routing logic accordingly inside RNBO.

You still would need of course develop an UI on the target platform.

Oskarsh's icon

I've built this patch which goes into the right direction. Basically you can define with the number on the left which effect should be played. However with this approach the Effects are duplicated which will result in a lot of parameters being exposed. I would like to only be able to have one effect per FX Slot.

Wil's icon


I think this will work -
Use feedback to stop audio feedback error
Then route by switching gate~

(maybe have to master the art of gates~! to not get infinite feedback)

Wil's icon

here is the same logic using Max tapin - tapout
this way you can use fx modules and switch them out easier
no feedback error
- same rule applies, don't open gate 1 to gate 1

(and it.s mc.able)

Roman Thilenius's icon

for only 4 effects (like somebody correctly calculated: 24 possible connections) i would also use gate~.

but for a bigger grid or graph - and for outside RNBO - it will of course be better to load those effects dynamically and leave the grid as is while you do.

Oskarsh's icon

If a Effect is not receiving any audio will this effect be bypassed and the cpu be saved?

Wil's icon

It seems no. I just did a test.

The test was build a patch that runs the cpu up 100% with a lot of effects and mc (over 200 channels). Delete the effects and CPU goes down to 60 %. Add the effects back but bypass them completely and CPU back to 100%.

Not sure but I think the effect is "active" even if it's being bypassed.

There are some posts about threads and bpatchers - but none of this solves the heavy load.

The best solution is to find your sweet spots and build up to there. Deleted whatever you absolutely don't need. Compose rather than...

The future will be here soon!

Roman Thilenius's icon

turning blocks on an off would be left to you. but doing this in RNBO... is an interesting topic.

Sébastien Gay's icon

In MAX, sending dynamically (script connect/disconnect) messages to [this patcher] could be an option, but I don't know how valid it is inside RNBO.

Roman Thilenius's icon

MSP objects themselves continue processing when disconnected.

what about a poly~ or a begin~ equivalent under the rainbow?

Jan M's icon

scripting patchers isn't possible in RNBO, as the final version is a compiled C++ program. To my knowledge it's currently also not possible to stop processing in parts of the signal chain.