Request - Nestable And Switchable Combinator

[visheshl]

So i was using Ableton group to rack feature.
what it does is you can group devices together into a rack. Basically like a combinator, however the Ableton Rack(combinator) is far far more flexible than the reason version.
Firstly, Ableton Live rack (combinator) can be nested.
So you can have combis within a combi within another combi. Etc.

Or you can have a main group rack combi , and have several seperate combis(chains) inside the main combi.

Now, the most amazing aspect is that you can, switch between the combis inside the main combinator with a macro on the main combinator so that only one combinator inside is active at one time and others are switched off. Now this can save valuable CPU.


what Ableton allows to do is to set ranges for each chain. And then you can use a macro to enable or disable the combinators inside the main combinator.
So let's say you have a main combinator, and you have four separate combinators inside the main combinator.
Now if you want you can map the on off switches of these combinators to a macro on the main combinator and set ranges on which each inside combi will be active
For example if the main macro knob is set between 0-10, the inside combi1 will be active,
11-20 combi 2 will be active and so on.

My request is to implement nested and switchable device groups or combinators like how Ableton does.
It would be a great feature to have and perhaps some thing which will make reason a far more powerful software.
And we could save a lot of cpu by having only one combinator active on each track at a given time.

[jam-s]

I don't think this is likely to be implemented as it sounds like a rather complex feature which could become a UI nightmare and would clash with the Reason philosophy of keeping things rather simple and hands-on.

[visheshl]

So why did they bother with combinators at all, combis are basically just device groups with macros.? All I'm saying is allow nested groups.

I think instead of becoming a ui nightmare it would become a ui dream.
It would help keep the rack well organised.
I'm pretty sure reason users are already creating functional groups and subgroups of devices. The only problem is that those groups and subgroups lack a proper container visually, which is the actual nightmare because you don't really know at a glance which device belongs to which group

[jam-s]

From what I've seen people use one combinator for each sound source and the respective sound forming FX chain, then possibly another few combinators as insert FX for those and then multiple Rack columns to keep stuff organised in groups. Having nested combinators would not help much here imho.

[visheshl]

Ok so i know You don't like the idea, however think about this usecase -
You have one main combinator, inside that you have four combinator instruments.
You map the power switches of these combis to a macro on the main combinator.
Now you can keep only one sound active at a time using the main combi macro.
Other combi sounds are switched off.
And you can toggle between these four sounds and even automate a single macro to switch between sounds. It becomes one sound/fx module with multiple sound/fx patches, of which only one patch is active at one time.
This would really save up on CPU.
Especially in RRP.
You could automate the main macro in every clip in Ableton session view for example.
Each clip switches on the particular sound it wants and switches off all other sounds in the group.
So you could have multiple sounds loaded on a single RRP track in any DAW and can switch between them easily as opposed to creating a seperate track for each sound and also automating the power switches of every RRP in every track seperately if you want to save up on CPU.

[visheshl]

Also i think loading ten devices in one single RRP vsti instance does not equal to loading one device each in a separate RRP Vsti instance.
I could be wrong but i think every seperate vsti you load in a daw does take up more resources.
Plus each separate Vsti needs a separate track in the DAW. Plus the devices in seperate vstis cannot share midi, CV data between them.

I think you're mainly a reason standalone user so you can't really understand the importance of nested combis in RRP.

Also it doesn't hurt to have the option available. Especially if it means saving up valuable CPU power and being able to have many more sounds in a project in RRP or even in standalone.
Those who want may use it, those who don't like it, don't use nested combis.
It's as simple as that.

[avasopht]

Nesting isn't complicated to implement - that's essentially how Reaktor works.

To keep the UI simple, nested combinators could have expansion disabled. That way they just appear as regular devices inside of a combinator. It's a reasonable compromise.

[visheshl]

Thanks, at least one person sees this as a useful feature to have.
Yup or you could have the option to open a separate window to display contents of a nested combi.
Not sure if this would complicate things.

But your option to disable expansion in nested combis works too.
If you really need, you could save the nested combi in a patch, open the patch separately, edit the patch and save. Now you could load up the patch in the nested combi.
Nested UI problem solved !!!

[crimsonwarlock]

You have one main combinator, inside that you have four combinator instruments.
You map the power switches of these combis to a macro on the main combinator.
Now you can keep only one sound active at a time using the main combi macro.
Other combi sounds are switched off.
And you can toggle between these four sounds and even automate a single macro to switch between sounds. It becomes one sound/fx module with multiple sound/fx patches, of which only one patch is active at one time.

You can already build this scenario without nesting, as you are free to cable outside a combinator into other combinators. The whole switching thing you describe can be done with REs. There's a bunch of them that can do things like this, most of them are free as well.

Besides, stacking combinators in the rack instead of nesting them is a cleaner solution tmo. Nesting always increases complexity, especially when you can nest into multiple levels.

This would really save up on CPU.

Not going to happen. Currently, switching any RE (or internal instrument/FX) to bypass or even off, doesn't actually stop processing of that unit. It has been requested for years now, to be able to save CPU that way. My guess is that it has something to do with how Reason implements all the cross-unit routing/cabling. This is also why track-freeze is hard to implement: For this to be efficient you need to remove the RE after bouncing to audio, as otherwise the RE will still consume CPU, and removing it would break any cabling. So the only solution is to be able to actually switch off processing in an RE, and that might need a substantial change to the RE SDK.

[visheshl]

Okay...i didn't know switching between devicesl chains was already possible. Would you be kind enough to link me to an RE(preferably free) which can do this ?

Ok so i understand what you're saying that reason cannot turn off processing of the devices.
So could they just do this for the Combinator only ?
That is give a switch to completely turn off the Combinator which would mean that any devices inside the Combinator would turn off too...that could be a way to implement this without messing with all devices within reason.
Then if you want a switching device you could do it with combis...then perhaps track freezing could be implemented with the Combinator too...at least it would be better than not having freeze function at all...

[crimsonwarlock]

Okay...i didn't know switching between devicesl chains was already possible. Would you be kind enough to link me to an RE(preferably free) which can do this ?

Switching audio:

https://www.reasonstudios.com/shop/rack ... -splitter/
https://www.reasonstudios.com/shop/rack ... ts-switch/
https://www.reasonstudios.com/shop/rack ... ut-switch/
https://www.reasonstudios.com/shop/rack ... audio-out/
https://www.reasonstudios.com/shop/rack ... ference-5/

Switching CV:

https://www.reasonstudios.com/shop/rack ... cv-switch/
https://www.reasonstudios.com/shop/rack ... cv-router/
https://www.reasonstudios.com/shop/rack ... et-cv-out/

These are the ones I use regularly. There might be more if you dig around the shop.

[visheshl]

Ok great thanks

[jam-s]

Ususally FX REs implement silence detection and then simply skip processing and thus automatically reduce CPU/DSP load. Instrument REs usually also implement some CPU saving when there is no incoming MIDI, but free running LFOs or oscillators still have to keep running for those.

[crimsonwarlock]

Ok so i understand what you're saying that reason cannot turn off processing of the devices.

I didn't say they can't turn off processing. I just said it's my guess.

So could they just do this for the Combinator only ?

If it is hard to implement for REs, I think it is even more complex to do it for combinators. But again, that is my guess. I don't work for RS.

[crimsonwarlock]

Ususally FX REs implement silence detection and then simply skip processing and thus automatically reduce CPU/DSP load. Instrument REs usually also implement some CPU saving when there is no incoming MIDI, but free running LFOs or oscillators still have to keep running for those.

Indeed, many REs show zero CPU load when idle. However, I have projects that, when not running, show 60% DSP load, so there's that.

I'm not complaining, though. I do understand that the whole cable plugging paradigm (across equipment, mixer channels, etc.) makes many things more complicated (software development wise) than it would be in other hosts.