Mix Down to One Audio File incorrectly includes the content of unwanted audio tracks

You did some great observations, thank you so much for taking the time to do this ! :pray:

1. → Yes, that’s the expected behavior.
2. → Exact, one track alone works, but not two. (keep reading, we’ll see below)
3. → Yes, that’s expected. It doesn’t work because it has to pick up the audio stream at the Master Output stage.
4. → a) , b) and c) : Right, expected, same as above. d) : Expected, since it listens to the Group it renders the Monitored signal but not what’s on the track.

Now go back to part 2. Using Channel Settings this is where the wild thing is :

  • Group is set to No Bus, right ? So the signal has nowhere to go after the Group, I mean the Group doesn’t go to any Master Output (although its signal can still be picked up as an Input by other Tracks).
    Rendering from one track works, because the signal is picked up before the Group Output, more precisely, before the Group panner (which is logical and expected).
    However, when we try to render from two tracks, with Mix Down to One Audio File, it seems that it wants to pick up the signal not before the Group Output, but somewhere after it, and since the Group doesn’t go anywhere, nothing happens, same as when using Complete Signal Path.

And that’s totally unexpected. Even though we are using Mix Down to One Audio File, it should just pick up the merged signals at the Group stage, just like when rendering from only one track, OR (because I don’t know what happens under the hood exactly) render each track one after the other, then mix the resulting files together. As long as the Channel Settings mode is selected, it should work like this, but for some reason it does not.

→ Now we know that the Mix Down to One Audio File option breaks the internal routing when using Channel Settings, which is also proven by my previous experiment with selecting only one side as the Group Output Bus :

This completely proves the Mix Down to One Audio File option picks up the audio at the wrong place, probably at the same place Complete Signal Path picks it up.
And actually, Channel Settings + Mix Down to One Audio File does behave the same as Complete Signal Path :

  • If you pan the Group (or just the audio tracks) and render with these settings, the panning is rendered. Clearly it should not, or does it ?

Actually it is expected if we take the time think about the rendering path. When you render multiple tracks into one, it simply cannot keep the settings of each track, so it has to render it.
So it isn’t really an issue…


This still does not explain why the third track spills back into the rendered signal !
Well, actually, it is directly related to the above.
Because this third track has the Group as its Input, the internal routing somehow becomes interconnected between these two channels.

→ I believe that the most simple answer tho this, is :
Since the Input Bus of the third track is the Group, it seems to be detected as part of the “Complete Signal Path”. In other words, it is detected as if it was a Send and processed as such, and that may be the reason why it captures the audio that’s already on the track, it actually reads the track, like if it was a plugin, so it prints down in the render. I don’t find any other explanation.

Now I feel bad to say this but, yeah, it looks expected from a rendering / routing perspective, but absolutely not from the user-experience perspective.
Cubase should be able to differentiate a plain Audio Track from actual Sends. Please say if you agree or not with this, but I think the Complete Signal Path should definitely not include Audio Tracks that have the Group as input. They are not supposed to be part of the direct Complete Signal Path, they are separate branches.

I any case, one real issue remains :
→ Complete Signal Path wrongly renders audio tracks that have the Group as their input.


I think this clears out your edit a bit :wink:
Cheers and thanks again for taking the time to investigate :beers:

1 Like