[Plugin now available] Would a "Sidechain Mixer" plugin be useful to anyone?

I read a thread a day or two ago here (can't for the life of me find that thread now), where someone used a Sonitus plugin as a way to create a "track bus" using its side-chain input, so you can have the bus in the same folder with other tracks (like say, multiple drum outputs feeding into one "drum bus" in the same folder).
 
Of course one can just use a regular bus for this, but I can see how a bus in the same track folder can be useful. 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. It should be trivial to create such a plugin, so I might have a go at it if there is enough interest. I can just modify one of my existing plugins and rip out everything and add just code to mix all inputs together.
 
Let me know.
-----------------------------------------------------------------------------------
 
EDIT: Updating with the post with the actual plugin info:
 
OK here is the plugin. It works as expected, with one caveat... If you solo the track bus, Sonar will not solo the tracks feeding into the track bus. To get around this, solo the whole folder, or group the solo buttons together.
 
To use: 

• Unzip the files.
• Copy the 32-bit and/or 64-bit files somewhere into your VST3 folders.
• Let Sonar do a scan.
• The plugin shows up under Plugins > Audio FX > VST3 > Sidechain Mixer (or wherever you put it).
• Drag/drop the plugin into the FX bin of the track that you want to convert to a bus.
• Set the output of any other track to "Sidechain Mixer(Input 2)-[track bus name].

 
Some points: 

• You can also send sends into the track bus.
• You need to set PC to Post-FX if you want the signal to go through PC.
• I only tested the 64-bit version so let me know if the 32-bit version doesn't work.

 
 

No, the idea belongs to LJB.
http://forum.cakewalk.com/FindPost/3050940
 
Thinking about this though...
Why not just allow moving a sub-bus into the track pane.
This way, there is no audio overhead involved. Just a display thing.

Silk,
Agreed.
And a plug would not break anything else.

Noel,
The idea is to allow a bus to be moved over to the track pane next to the channel strips that feed that bus.
It is not a routing thing it a UI thing.
LJB came up with the idea of using the side chain of a gate to accept sends and hence simulate a bus which can then be placed in the track pane of console view and track view. (think of the way Reaper places buses...almost like a folder)
What we really want is not to have buses limited to positioning in the bus pane on the right.
LJB's method is ingenious but complicated.
Silktone is suggesting a quick and dirty plug to accept sends from other tracks/buses and simply mix them. The plug could be inserted into a track and create a 'virtual' bus with UI properties of a track and the summing functionality of a bus.
This would allow placing the 'virtual bus' into the track view track pane and console view track pane.
The same idea (unlimited UI placement of real buses) is in Features & Ideas and has been mentioned in several threads.
 http://forum.cakewalk.com/FindPost/3151211
 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.

OK I think the slow debugging was due to AD2.
 
BTW I realized I was using the VST 2.3 SDK, which doesn't support 64-bit processing. So I downloaded the VST 3 SDK and am using that instead. It might take a bit longer as I need to get up to speed with it first. I think VST 3 supports side chaining directly so I'll need to figure out how that works.

SilkTone

Noel Borthwick [Cakewalk] 
Hi no sure I follow why this is even necessary. All outputs that are assigned to a given sidechain input of a plugin are automatically mixed by SONAR prior to delivery to the plugin SC input. So all you need is a dummy pass through plugin that has a sidechain input. Assign as many track or bus outs to that input and you get auto mixing. The level of the individual inputs is controlled by the send gain. This will allow you to route tracks to other tracks.

Noel, the topic of a bus in the track view has come up a few times in the past. Sometimes it is convenient to have everything visually together (including a dedicated bus). I realize this isn't a high priority feature and that there probably aren't many people that need it, but it would still be nice.
 
The reason I started this thread was that after thinking about LJB's thread and how easy it would be get the desired functionality with a very simple plugin, that I would just go ahead and take a stab at it.
 
I've been playing around with it, basically a plugin that has 4 inputs and 2 outputs. Inputs 3 and 4 then becomes available as a side-chain input for any other track. And as you mention, we can assign as many tracks as we want to those two inputs and all that is required would be a simple block memory copy of channels 3 and 4 into the 2 output buffers. So there isn't even any mixing required in the plugin (not that it is hard or would add any artifacts or use a lot of CPU). I'm wondering what should happen with inputs 1 and 2. They should probably just be ignored, in which case any input directly into the "track bus" would not make it to the output. But that seems fine.
 
Noel, somewhat unrelated, but maybe you can give me a quick tip... I noticed Sonar Platinum is extremely sluggish under the debugger. It starts up extremely slow (a few minutes each time), and it keeps freezing up. It was never like this. Any ideas? Are there a special mode I can put Sonar into or something along those lines? I am using AD2 as a signal source, maybe it is causing this behavior?
 
Edit: Haha, just deleted all the empty lines. It was actually my cat that stepped on the keyboard. At 1st I thought he somehow deleted the whole post, but it just scrolled off the screen.

Me, I want it for two scenarios.  
 
Yes, I like to have a general level bus mix next to the instruments that are going to it.  It keeps me from having to jump to another view or screenset just to bring up the acoustic guitar tracks for example.  Or I might have three tracks of one guitar - close mic, one maybe back a bit or a different mic and a room mic.
 
The other is where I am parallel processing a track and blending it back in with the original.  I'll create an aux next to the snare track and then crush it, distort it or EQ it in a different way and then blend it with the original.  

I think it would be great. With the sophisticated software we have I don't think there's a reason to stick with the hardware mixer model where buses and inputs have fixed locations. The flexibility of being able to have everything in a folder would be great. Also in console view it would be great to see the "bus" next to the tracks

SilkTone
I've been playing around with it, basically a plugin that has 4 inputs and 2 outputs. Inputs 3 and 4 then becomes available as a side-chain input for any other track. And as you mention, we can assign as many tracks as we want to those two inputs and all that is required would be a simple block memory copy of channels 3 and 4 into the 2 output buffers. So there isn't even any mixing required in the plugin (not that it is hard or would add any artifacts or use a lot of CPU). I'm wondering what should happen with inputs 1 and 2. They should probably just be ignored, in which case any input directly into the "track bus" would not make it to the output. But that seems fine.
 
Noel, somewhat unrelated, but maybe you can give me a quick tip... I noticed Sonar Platinum is extremely sluggish under the debugger. It starts up extremely slow (a few minutes each time), and it keeps freezing up. It was never like this. Any ideas? Are there a special mode I can put Sonar into or something along those lines? I am using AD2 as a signal source, maybe it is causing this behavior?

 
Inputs 1 and 2 should be passed through unmodified otherwise in the default case it would silence the track it was inserted on :) If 3 and 4 are present they should be summed into 1 and 2 respectively.
 
Not sure why its sluggish, for you since we don't have that issue - maybe you have your symbol server set up to go to the MS servers. That will be slow since it goes out to the internet to get symbols. 
 

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.

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.

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.

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.

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.

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 ?