i typically set up a minimum of 6 busses.


Master (takes output to sound card)(all 'sub-busses'  go to master)

Vocal
Drums
Guitar
Bass
Keys
FX1
FX2





typically, i'll have two FX busses, one a reverb, one a delay

sometimes, i'll actually mix songs using automation on the busses, instead of automation on the individual tracks.
it all depends on how i tracked the song.

but it's infinitely variable.

for example, the way an individual bass guitar track responds to a LIMITER on the FX bin of that track, can be different than the way it will respond with the same limiter, same settings, on a Bass Sub-Buss, with the re-direct of the track from master to BASS BUSS....

because of gain staging.

sometimes, one way is better than the other, but you have to have the practical experience to know which is better for a given situation.

saving CPU is one issue....
gain staging is another.

having total control over the eq of an entire group of vocal tracks, using just one EQ plugin...
versus having a EQ plugin on each of 10 different vocal tracks.....you can see how the economy of busses can be used to advantage.

multiple guitar tracks?
multiple bass tracks?

separating Drums into drums versus cymbals versus overheads?
with different Busses for each, and different FX busses setup for each drum sub-buss?

it can get very creative.
and complicated.

yep - I'm getting the picture.  Thanks for the examples, I have actually been using busses for a little while now, as opposed to dumping a variety of FXs on each individual track - quickly saw the economy of that as far as CPU usage and overhead - but was bothered by the knowledge that you can't treat every track with the same FX and settings.

For instance, vocals -   lead and BGV don't (usually) get the same treatment of EQ and Reverb, yet that's what I was doing because I thought that was the "more correct" way to do it.   Now I'm seeing why you set up multiple busses and sends and economize on how many instances of FX used, yet still get the individual control you want per track.   I can't say that my head doesn't hurt a bit today mulling over all these great comments - but I can't wait to start putting all this good stuff into practice.  

Though it was  a mean to simplify things, the way Cakewalk implemented busses can be a bit confusing. And understanding busses and signal flow can be a bit tricky, anyway.

Because there's no such thing as audio channels in Cakewalk software and no distinction between tracks and channels - which can make things easier at first - imho, it makes understanding signal flow a bit more complex. It's also less flexible.

A Send (or Aux Send or FX Send) is an additional/alternate output for an audio channel/track. It is used to route the signal to a bus. 

Metaphorically speaking, a bus is a virtual vehicle which you use to route one or more audio track to a destination, and the Send is the gate which allows passengers (tracks) to enter the hangar and climb on one of the busses. 

That bus can then assigned as the input on an auxiliary channel - which is basically similar to a regular audio channel to which no audio track is assigned and on which you cannot record. It is used to stream audio and/or process it. That auxiliary channel becomes the Bus destination.

Unlike Sonar, some applications will also allow you to set the destination of a Bus to a regular audio track, so that you can effectively record that Bus' output. (More on that below.)

Of course, your audio tracks can climb on many different busses at once and be sent to various destinations for different purposes. (as in Mike's Y split example).

In Cakewalk software however, busses are automatically tied to an auxiliary channel (which is also automatically created), hence the reason they refer to them as "Aux Buss" IIRC. Just like they don't differentiate tracks and channels, they don't differentiate busses and auxiliary channels.

Though the way Busses are implemented in Sonar makes things easier on one hand, it also can leave you scratching your head when you read or watch tutorials about busses and sends in a non-Sonar environment because it's a highly custom/non-orthodox way of working. 

Sends, Aux Sends, FX Sends, Busses, Aux Busses, FX Returns, Aux Channels - just the terminology is enough to confuse us. ;) But it's basically 3 things - an output (send), a transit (bus) , and an arrival point (an input in the console).

To illustrate that... In other applications which mimics the hardware paradigms more closely (using "channels"), like Pro Tools or Logic, here's out it works.

You click on Send and select a Bus from a list:




Metaphorically speaking again, that's where the passengers (audio tracks) are walking through the hangar gate (Send) and a climbing on one of the Busses.

Up to that point, however, the Bus isn't going anywhere just yet - it isn't assigned to any channel, it has no output. It has no destination and is still in the hangar.

So you then assign that bus to the input of either an audio channel or, more often, an auxiliary channel. This channel becomes your Bus' destination and you passengers can now be taken to that destination.

In the image below, after creating several possible destinations (auxiliary channels), I'm selecting which bus will arrive where by assigning them as an input to a channel.

So anyone who climbs on Bus no 2 will land in Aux no 4.




As you can see, the auxiliary channel offers the option to use any available input - hardware inputs, busses, etc... 

Aux 1 has no input yet. Aux 2 has one my Audio Interface's inputs selected as a source. Aux 3 is set as the destination for Bus 1. And Aux 4 is set to Bus 2 (checked) but also shows all the available inputs which could be used.

You would use hardware inputs if you were using an outboard fx unit for example, to route its outputs (aux return or fx return) back inside your DAW. 

Regular audio channels offer the same flexibility in terms of input. The main distinction is that you can use them to record audio, unlike auxiliary. 

In other words, in Sonar, Busses are more or less a set destination, whereas in some other applications, they are a mean to bring your signal to a destination.

Of course, you may not need the info, but maybe it can help you figure out how things work, particularly if you see someone doing something cool w/ busses in another application and try to do the same thing in Sonar, because they often use different terminology.

Rain, I really appreciate the details and pics you posted.  Taken together with the earlier post referencing RobertB's documentation also, this is a much more clear concept to me now between bus vs. send.  Some of it's terminology and the rest is how the particular DAW software allows us to redirect or add (or even split) that data into other parts of the chain.   I think  you're right too, that CW seems to make little/no distinction between tracks and channels - which has sometimes confused me.  I also faithfully pour through the video tutorials that CW has, i.e. the Sonar University videos, and for instance did not see any distinction between a bus and a send as a selection option, the speaker tended to use the 2 terms interchangeably when showing us how to assign a bus. 

I'm wondering if any of this will be any more clear in Sonar X2 with the new "lanes" concept?   It would be helpful for folks at my level if there was somehow more of a visual cue to help keep the various data path assignments straight.  Maybe it's just a matter of time and repetition.   And trail and error.   At any rate - many thanks for all the above help!     -John