BTW, I wonder what name makes the most sense... "Sidechain Mixer", or "Track Bus". The first is what it does, the second is what it's purpose is. If it was "Track Bus", then the name in the context menu when selecting a track's destination would become "Track Bus(Input 2)-[name of track]". That might be a bit more descriptive, not sure.
 
 

Track Busser. 
 
Bus Stop.

SilkTone
 
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:
 

Yes, I'm aware of that. I was talking about the case when you have several tracks which share the same name, so the sidechaining would look somewhat like this:
 
Sidechain Mixer A(Input 2)-Guitar 1
Sidechain Mixer B(Input 2)-Guitar 1
Sidechain Mixer A(Input 2)-Guitar 2
Sidechain Mixer B(Input 2)-Guitar 2
Sidechain Mixer C(Input 2)-Guitar 2
 
So this would be 5 different tracks which share names between each other.
But thinking about it again, I think you are right, this really is not necessary and probably would just screw up things.
 

Andrey, the name shown in the context menu would be that of the destination "track bus", not the source track. So it would instead show something like "Sidechain Mixer (Input 2)-Guitar Track Bus" (depending on what you called the "track bus"). So you might have something like:
 
Guitar Track 1 -> Sidechain Mixer (Input 2)-Guitar Bus 1
Guitar Track 2 -> Sidechain Mixer (Input 2)-Guitar Bus 1
Guitar Track 3 -> Sidechain Mixer (Input 2)-Guitar Bus 2
Guitar Track 4 -> Sidechain Mixer (Input 2)-Guitar Bus 2
Guitar Track 5 -> Sidechain Mixer (Input 2)-Guitar Bus 2
 
Am I missing what you mean?

We'll think about doing track to track routing. Its been on the plate for a few years but there have been other more features that took precedence. Our architecture already supports this since internally tracks are really just a superset of buses as far as the engine goes. Buses already allow you to send to other buses so allowing tracks to send to tracks will be an extension of the same thing.
Some UI changes would be required to accommodate this. I imagine we wouldn't want to always show tracks as destinations since it would clutter the UI for the normal use case since this is a far less common requirement.

Silktone, now I get it, I was not being clear enough, sorry for that. What I meant was not summing several tracks in one track bus but rather the opposite - I was talking about distributing one track via sends into several "track buses". And only then summing the whole thing up. Think of it like this:
 
Guitar Track 1 send -> Sidechain Mixer(Input 2)-Guitar 1 Subtrack A 
Guitar Track 1 send -> Sidechain Mixer(Input 2)-Guitar 1 Subtrack B 
Guitar Track 1 send -> Sidechain Mixer(Input 2)-Guitar 1 Subtrack C
Guitar 1 all the Subtracks output -> Sidechain Mixer(Input 2)-Guitar 1 SumABC
et cetera.
 
That's why I thought different dll names could come in handy. So this would be something like:
Guitar Track 1 send -> Sidechain A(Input 2)-Guitar 1 Subtrack
Guitar Track 1 send -> Sidechain B(Input 2)-Guitar 1 Subtrack
...
 
But, again, since you mentioned it, I think it's really unnecessary. I take it back.
 

Noel Borthwick [Cakewalk]
Some UI changes would be required to accommodate this. I imagine we wouldn't want to always show tracks as destinations since it would clutter the UI for the normal use case since this is a far less common requirement.

Yay!
Maybe some sort of a button - somewhere near the Freeze and Archive buttons which would make the track's input visible to sends and outputs? Sort of like that sidechain option in CA2A in PC - it's sidechain input becomes visible in the list only if you turn CA2A on first.

Noel Borthwick [Cakewalk]
We'll think about doing track to track routing. Its been on the plate for a few years but there have been other more features that took precedence. Our architecture already supports this since internally tracks are really just a superset of buses as far as the engine goes. Buses already allow you to send to other buses so allowing tracks to send to tracks will be an extension of the same thing.
Some UI changes would be required to accommodate this. I imagine we wouldn't want to always show tracks as destinations since it would clutter the UI for the normal use case since this is a far less common requirement.

It would be important that the routing be accomplished via the input of the destination track (or some means other than the source track output).  IOW, we would need both the source track and the destination track able to be sent to a bus or main outs via the track output.

I understand the request but why is it important? :)

microapp

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 ?

I'm trying to see the purpose of this. I can't. It would be like having a type 0 MIDI file.