Noel Borthwick [Cakewalk]

microapp
 My suggestion (and Mod Bod's) is simply to remove the UI limitation of buses only positioned in the bus panes. This would not add additional audio routing and overhead and involve just a UI change.

Its not quite as simple as you might imagine. Buses and tracks in the UI are vastly different entities and the UI that manages them is quite different. This is because tracks existed eon's before buses did in SONAR. Changing that logic would take a lot of re-architecture of the UI, so it would be hard to justify the cost.

I started to write a whole spiel about OOP but I think I will just say...
I guess we are on our own then.

Noel Borthwick [Cakewalk]

microapp
 My suggestion (and Mod Bod's) is simply to remove the UI limitation of buses only positioned in the bus panes. This would not add additional audio routing and overhead and involve just a UI change.

Its not quite as simple as you might imagine. Buses and tracks in the UI are vastly different entities and the UI that manages them is quite different. This is because tracks existed eon's before buses did in SONAR. Changing that logic would take a lot of re-architecture of the UI, so it would be hard to justify the cost.

 
So what about my suggestion of an additional customisable Console View.
Would that be feasible?

If we could just create mono/stereo aux tracks in the track view and assign them to a bus. Pro Tools do it all the time. The aux stays in the track view and would be for multiple uses.
I don't want Pro Tools, but this would make it easier for everyone in Sonar.

If we did it the concept of an aux track would be much more feasible than trying to mix buses into the track view. Buses and tracks have two different functions. Buses are for mixing/post-processing as opposed to tracks that have input data. I personally find mixing tracks and buses in the same view a schizophrenic concept. I understand the requirement to pair the UI but it seems like a huge investment for a minor gain.
Another possibility (thinking aloud) what if we had an auto track zoom mode that magnified and showed the track and its destinations when you clicked the track. Would that be helpful?

Noel Borthwick [Cakewalk]
If we did it the concept of an aux track would be much more feasible than trying to mix buses into the track view. Buses and tracks have two different functions. Buses are for mixing/post-processing as opposed to tracks that have input data. I personally find mixing tracks and buses in the same view a schizophrenic concept. I understand the requirement to pair the UI but it seems like a huge investment for a minor gain.
Another possibility (thinking aloud) what if we had an auto track zoom mode that magnified and showed the track and its destinations when you clicked the track. Would that be helpful?

Hmmm, that's interesting.  
 
If I'm understanding that correctly, you select a track, press a hotkey (or mouse to some out of the way button for our mouseketeers) and you would see the source track(s) and next to it in the console view, you would see the bus pane with all busses that the selected track(s) is/are routed to.  Of course, for the Track Pane, it would do the same and bring up the bus pane there as well.
 
It's better but not quite satisfying.  A bit like when I ordered iced tea in England and I got a small pot of hot tea, a tea cup and a single ice cube.  I smiled and said, "You don't get it, do you?"
 
BTW, I like the concept of an Aux track better and/or being able to rout a track to another track via an input selection.  In PT it's all about creating and configuring I/Os which is something that would drive the majority of SONAR users absolutely mad but once you have got your head wrapped around that concept it opens up so many possibilities for routing tracks to auxes, tracks to tracks and so on.

Hi Noel,
I wouldn't mind the concept of an aux track. Really for me the principal use case is having both mics on a multi-mic'd instrument summed into another track that lives right next to them. So, both the inside and outside mic of a kick drum (or top/bottom on a snare, or neck and bridge of an Ac.Git etc) feeding an aux that wasn't in the bus pane. The ability to freeze would be cool (see what I did there  ) but not a requirement for me. I know you can do that with buses currently, but I just like the organization of having both mics on a summed "Kick drum" track in the track pane.
 
In a perfect world it would work as I outline here: http://forum.cakewalk.com.indPost/3153287 but that may not be feasible.
 
Dean
 
(edited to not have an embarrassing typo in Noels name...)

Noel Borthwick [Cakewalk]
If we did it the concept of an aux track would be much more feasible than trying to mix buses into the track view. 

Noel, Aux tracks would be nice (for me, at least). Or ability to route send from one track to the input of another track. Something like that.
 
Can I add some use cases to the conversation? I think it's just not a lot of people actually understand why would one need such a thing. I promise to exaggerate only a tiny bit for illustration purposes (and yes, I know that bus strips can be narrowed).
 
1. Ok, for a start, a "simple" scenario: suppose I'm writing a metal/nu/core/etc track with heavy, low tuned guitars. I want to mix and match different cabinet impulses and maybe different amps per one guitar. Also I want to do a lot of cutting-pasting-audiosnap-grooveclip-melodyne-etc post record editing on the parts, so I want to keep one guitar part per one dedicated track, no tracks' duplicating (otherwise it will take a lot of deleting and dragging of clips up and down across the multiple tracks after each edit and I eventually will screw up something somewhere). This means I will need lots of buses. All right, so I'm routing one guitar track with an amp plugin (just the amp, no cab) on it to 3 buses with the following effects:
 
bus 1 has cabinet A closeup and PC eq,
bus 2 has cabinet B closeup and it's own PC eq curve (which is different from bus 1's ) and
bus 3 with cabinet A room/back mic (need I mention it's own PC eq?)
 
Ok, that's not so bad, it's just three more buses. But now I'm setting up a second guitar track which plays same notes but with a different amp. I'm routing it to these 3 buses and after I listen I want it to have a bit (or maybe more than a bit) different sound. All right, I reroute "guitar track 2" to 3 new buses. Now I have my guitar doubletrack set up... Now, this monstrousity needs to be routed into bus 4 which is called "GuitarsDbl 1" and has a multiband comp (to smash those 160-200hz peaks) on it. At this point my project has 7 buses dedicated to guitars. I can live with that, but wait.
 
Now comes the second double track - I want that heavy and dark quadruple sound. I don't need that much of a cabinet choice for the second double track, so I create two buses per guitar track:
bus 8 has cabinet C off axis on it and
bus 9 has cabinet C room.
 
I add buses 10 and 11 for guitar track 4 and route all four buses to "GuitarsDbl 2" and put another multiband on it.
Now my project has... wait... 12 buses dedicated to guitars: six buses are routed to "GuitarsDbl 1" and four buses are routed to "GuitarsDbl 2".
Now I need to set up the bass track, and I need at least a DI and an Amped signal flow in parallel... Well, you're getting the idea. And keep in mind that all that needs to go into a final "Bass Sum" bus.
So: now my project has 4 guitar tracks, 1 bass track, 1 instrument track for drums - that makes it 6 tracks.
And 16 buses.
 
2. Now for a more complicated scenario. So, suppose I am writing this electronic idm piece with lots of ducking. I'm experimenting. I've come across a cool effect - multiband ducking (by the way, try it, you'll love it). It takes 3 buses per each melodic instrument. I've got, say, 12 instruments not counting the drums (which go into sidechain input). I need... oh god. 36 new buses. And these buses go to the bus pane (duh!) and clutter there everything even in narrow strip mode. Compare this to 36 new tracks which, by the way, can go into a folder. Much nicer, eh?
 
3. Now even more complicated scenario. I'm experimenting with multi-band exciting mixed with multi-band transient processing. I've got 4 vocal tracks and 3 acoustic guitar tracks. I want a 5-band processing per each track. I cannot route 2 or more tracks into one "fx processor" because there is a distortion (for the exciter part) in the signal chain. This results in 7 tracks and 35 buses (plus additional 2 buses for grouping all that and a master bus).
 
Now, I personally have almost no problem with using a Sonitus Gate in a "listen" mode to create fake aux tracks which go into tracks pane and nicely sit in corresponding folders. Except for one thing: routing is lost with track templates. I assume it's because when track templates load, first the tracks are created, then the routing is processed and only after that the FX are loaded. And that order ruins routing: you can't route a track to an input if that input is absent at the time (and will be loaded afterwards).
 
Sorry for the long read. I really wish I could explain that in a more condensed manner.

SilkTone
 So my question is whether it would be useful to have a dedicated plugin that can be inserted in a track FX bin, which would then become the side-chain inputs for any other track.

Silktone, I would definitely love to have such a plugin. Can I add a tiny feature request? It would be cool if it would be 4 dll's with 4 different names, something like "Sidechain A.dll", "Sidechain B.dll" and so on. Just for easying up the routing process. I hope it doesn't take much extra work, you'd just need to generate different VST ID's for each dll if I'm correct. And those who don't need this can always delete extra dll's from plugins folder.

Noel Borthwick [Cakewalk]
Its not quite as simple as you might imagine. Buses and tracks in the UI are vastly different entities and the UI that manages them is quite different. This is because tracks existed eon's before buses did in SONAR. Changing that logic would take a lot of re-architecture of the UI, so it would be hard to justify the cost.

Noel Borthwick [Cakewalk]
If we did it the concept of an aux track would be much more feasible than trying to mix buses into the track view. Buses and tracks have two different functions. Buses are for mixing/post-processing as opposed to tracks that have input data. I personally find mixing tracks and buses in the same view a schizophrenic concept. I understand the requirement to pair the UI but it seems like a huge investment for a minor gain.
Another possibility (thinking aloud) what if we had an auto track zoom mode that magnified and showed the track and its destinations when you clicked the track. Would that be helpful?

I guess there would be no point in requesting MIDI buses then.
What would that be... a paranoid concept ?

AndreyB

SilkTone
 So my question is whether it would be useful to have a dedicated plugin that can be inserted in a track FX bin, which would then become the side-chain inputs for any other track.

Silktone, I would definitely love to have such a plugin. Can I add a tiny feature request? It would be cool if it would be 4 dll's with 4 different names, something like "Sidechain A.dll", "Sidechain B.dll" and so on. Just for easying up the routing process. I hope it doesn't take much extra work, you'd just need to generate different VST ID's for each dll if I'm correct. And those who don't need this can always delete extra dll's from plugins folder.

Andrey, I don't believe that should be necessary. Look at this screenshot of the context menu when selecting the output destination of a track. The name of the "track bus" shows up in the context menu:
 

 
EDIT: Can't get the picture to show up here, so here is a direct link to the screenshot.