Side Chain architecture question


If I want to route a SC from one place to another, I need to SEND from the source to the destination SC…This is OK but what if I need to sidechain lets say 10 destinations and its not possible to route the destinations to a group channel? I will need to make 10 sends from the source right?

I am new at CB and come from Logic, where it works the other way around. You select where to receive from from the SC destination, so 10 destinations can select for example “kick send” as source. This can be better sometimes, although CB:s opposite way has it´s virtues as well… But I wonder if someone has a smart workaround for the situation where many destinations need to receive from 1 source?

thanks a lot!


I create SC “broadcasting” arrays of group channels, usually about four of them: SC (Part 1), SC (Part 2), and so on. Each feeds into the next to create a single long chain of side-chains. The 4 chained channels just null-terminate (they don’t connect to an audible output). This gets around Cubase’s horribly arbitrary and outdated 8 send limit.

The 4 new group channels (that act as one), each with its 8 slots for sends, combine to a total of 32 sending areas.

Now, just send your kick to the SC (Part 1) – it will flow through all 32 slots. You’ll have 32 slots to play with, to send out to the various group channels and stems with your Pads, Noise washes, Risers, etc. I mean, a little SC on just about everything, is not off the table. :mrgreen:

Ok thats a way to to it, thank you.

Not sure why CB is using the “send source to destination” instead of the “receive from source” sidechain paradigm…It must be loads more common to use one source and many destinations.

Glad to help.

Yeah, It has to do it that way to easily deal with its (unfortunate) 8 send limit. :mrgreen:

If it didn’t, and you were wanting to “receive from source” from a particular channel, and you did that on more than 8 different channels, it would have to deal with presenting an error message, or greying-out those sources, etc. Kind of a UI nightmare.

The way it is now, it deals with the limitation right at the source (pun intended). :laughing:

I think the Cubase sidechain setup is more flexible than the “receive from source” method because you can have multiple sources feeding into the same sidechain. e.g. Maybe you want to have the kick track AND the snare track sending to the sidechain, maybe you want them both sending at different levels, perhaps you want to automate the send levels in different parts of you song. These things are only possible with the Cubase style sidechain setup.

Yeah, great point.

I’m actually doing just that in several projects and didn’t really think about it, in that light.

I do it often by using for example one kick drum track sends to destination instruments or group tracks. 8 sends per track is more than I could ever need.

Rebumb - because I think I might be having the same problem. Working in the recently updated Cubase Artist 7.5.20. I activate the sidechain on the compressor on my instrument channel. When I try to send the signal of my kick (or any other audio source for that matter, I’ve tried different types of channels) via one of 8 ‘sends’, the sidechain-compressor is simply not listed as an option. Strange thing however is that the sidechain-compressor IS listed as an option on the output bus (where normally it is set on ‘stereo out’). Here it is working, but I don’t think this is the right way to sidechain. Btw, any FX-channels I create DO show up as send options, and they work just fine.

I am a bit confused, am I doing something wrong or is this a bug? I haven’t worked a lot with sidechaining, but for as far as I can remember I could always just simply use the sends option. It seems I have this probem since the 7.5.20 update (if it is a problem). I have tried different channels/instruments/sources and all appear the same. Restarting cubase did not solve the problem (also starting a new project did not).


edit: I think it’s the same bug as mentioned in this topic (saw it only now): / any solution?

There’s no bug… Cubase works perfectly. I suggest you go on YouTube and learn how to sidechain properly… There are many ways to do it :smiley:

Good god. I am so stupid. I was looking at the right click menu, and had not noticed there was also a drop down menu at the right side of the slot.

I will just go sit in a corner and quietly be ashamed of myself, haha. Thanks!

I think you’re forgetting that receive from source means that YOU decide what that source is, it’s highly flexible.
Cubase is highly inflexible in this regard because it does not allow you to choose a bus as a sidechain (which could be common over multiple plugins, if you wish) but instead creates a unique bus for each plugin.
This is not flexible at all, it’s restricting.

I come from Pro Tools, where you can select any bus as a side chain.
You can have multiple sources feed ONE sidechain,
you can have one bus feed multiple plugin’s sidechains,
you can have one source feed one sidechain,
and you can have a mix of sources feed multiple sidechains.

You can do whatever you want and that’s the way it ought to be.

The way Cubase handles sidechains, bussing and group channels is handy for simple use but it is severely limiting for elaborate routing. It is not better and it is most definitely not more flexible.
I don’t know how Logic does it, but I’m physically getting headaches trying to recreate my Pro Tools template and routing in Cubase.

let’s say you want to send the same side chain signal to twenty compressors…
You’ll need twenty sends. Let’s say you decide you want to try another compressor.
You’ll need to (re)create twenty sends again. Each time.
No it’s not better, it’s much much worse.

I do hope they change this amateur proof behaviour, at least in Cubase Pro. It’s driving me nuts.

I would like to set up a side chain signal from my final mix bus that I can use to trigger limiters on every stem or group channel that eventually ends up going out the final mix bus. Has anyone tried this and how would this be set up. Thanks.