When using the Mix Down to One Audio File option when rendering, under certain circumstances, it will wrongly include the content of other audio tracks whose Events aren’t even selected for rendering. Group routing is involved in this issue.
I’m not sure how to properly describe the issue in just a short sentence, so here’s the reproduction sequence. I’ll include a screenshot that shows the proper routing and result.
Repro sequence :
Add two Audio or Instrument tracks, and put content on them (audio or MIDI),
Add a Group track,
Add another Audio track, and put any audio content on it (possibly, different than the two other tracks),
Route the two first tracks Output to the Group,
Set the third track Input as the Group.
Make sure the Events on all three tracks are roughly aligned,
Select the Events on the first two tracks,
Make sure the Event on the third track is not selected.
Open the Render Settings, and choose Channel Settings and Mix Down to One Audio File,
Hit Render.
→ RESULT : The render prints down the third track in it !
It will only happen when Events from two different tracks are rendered, as shown in the above screenshots. It doesn’t happen when rendering Events from only one single track.
This happens as long as one of the tracks in the selection is routed to the Group, so all the tracks do not necessarily need to be routed to the Group, only one is enough.
This only happens when the record track (third track in blue) isn’t muted nor monitored. When it is muted it is not printed down in the render.
This only happens when the record track has an output connected. If there is no output, it will not print down in the render. Additionally, any output can trigger the issue, and if you select only one channel, it will only print down that one side.
The track in blue only has the Group as the Input so I can easily record VST Instruments as audio in real time. The example shows it with Audio tracks but the result is the same with MIDI.
Finally, the blue track Output goes to my speakers, so how the heck could the audio on that track be sent back to render ? According to my routing that’s totally impossible.
Please fix this infamous bug as soon as possible ! This is unacceptable !
Unless I’m missing something ?
EDIT : Please read Post 11 for further informations.
This requires serious investigation by the development team !
Louis, do you stumble accidentally on things like this or do you actively search for them? I would never dream of such a setup (tbh, I didn’t even know you could rip events from different tracks…)
I’m sure you thought of it, but as you didn’t post you render in place settings, they are on “dry” or “channel settings” and not accidentally on “complete signal path”? But that couldn’t explain why it only happens with two tracks…
Well, I randomly found this one while testing the Spitfire dropouts bug, so no, I don’t actively search for them. Stumbling across bugs in every corner is tiring enough already
If I did not share more info about the render setting it’s because it’s not relevant. It doesn’t matter what settings you use, you just need to enable that one option I mentioned.
But you’re right, I’ll add a note for it.
Thanks for pointing it out.
btw, I just reproduced this. Really weird. If you mute the “group record” track or set its output to none, it all works fine of course… You would think that with the render option “channel settings”, it would fetch the output signal after the panner of each of those tracks…
Haha I did not catch this ! Nice one.
And if you only choose the L or R channel for the output it only includes that side.
Something’s very wrong in there !
Btw, Channel Settings does not render the panners, only Complete Signal Path does. But what would that change to the issue ?
I don’t see this. In my case, if I select only the event on track Audio 02 (I will use your naming) and render it, I’m still getting Audio 03 (Group Record) (in my case a drum loop) in the rendered event.
Yes. When I mute the Audio 03 (Group Record) track, every single render comes through untainted, be it on one track, or two tracks.
Some observations of my own.
If you activate Monitor on track 3, the signal of Tracks 1&2 in Stereo Out is doubled. (Sum from Group 1 → Stereo, Monitoring Group 1 on Track 3 → Stereo Out)
Now, if you select both events on Tracks 1 & 2, while track 3 is still in monitor, and render them, you get the same amplification in the render.
If I use Export mixdown… for just Group 1, the produced file is clean from track 3 content as expected.
So, I don’t really know what’s to blame here. There’s definitely something going on with what Render in place does. It’s as if it takes both signal paths to the stereo out, but, and here’s the evil twist, it doesn’t render just the input side, where the signal is, but the events on the track instead. Does it see Group 1 and go “Ahh, there’s valuable signal here, let’s follow it through to the input of a totally unrelated track!”?? Pffff. Confusion!
Actually the issue also happens without the third track.
It seems that the culprit is the Group itself.
Please try the following experiment :
Just remove the third track, and select No Output for the Group.
When you render the Events on one track only, it works fine.
However, if you render the Events on two tracks, nothing happens !!
If you disable Mix Down to One Audio File, the issue goes away completely.
Now enable Mix Down to One Audio File once again.
On the Group Output select only one channel (L or R).
When you render the Events on one track only, it renders in stereo properly.
Now render the Events on two tracks, and observe that it only renders the same side than what is selected in the Group Output !!!
Not only that, but it doesn’t matter which Output is selected for the Group, even if you create a dummy output in Audio Connections with no physical channels assigned, it will still make that weird mono bug !
The same happens with the third “Group record” track, when you select only one channel as the Output, only that channel will be printed down in the render, and the two combine ! You can have the two Audio Tracks on the Left channel, and the Group record track on the Right, this is totally independent.
Now, and I hope this will be the last thing :
Go back to the initial setup, but instead of choosing Channel Settings in the render dialog, choose Complete Signal Path instead, and disable Mix Down to One Audio File.
If you render any of the Audio Tracks (can be only one), the third track will still print down in the render ! Which is probably why you said @ggmanestraki , that it happened when rendering from only one track.
I was wrong saying that it happens regardless of the signal path setting; sorry @fese .
It seems that Channel Settings + Mix Down to One Audio File behaves the same as Complete Signal Path internally.
And last but not least – very important :
When the Group and the Record Track have a different Output, the Mix Down to One Audio File option is grayed out when choosing Complete Signal Path, whereas it can be selected when the Output is the same. Yet the two tracks aren’t event related, the audio track only catches the Group signal so it can be recorded. Their output are supposed to be totally independent ! So why is that ?
As far as I know rendering doesn’t require any output to be set when using Channel Settings, even when tracks are routed to a Group. When the Group has no output selected, rendering one Event from one track works properly, but as soon as we select Events from two tracks or more it fails ?
And why the heck does it exhibit this weird L/R bug when rendering when only one channel is selected as the output ? And why it does this only when two tracks or more are selected for rendering ?
Somehow the Outputs are involved in this, but why ? And most importantly, how ?
So all the following is involved in this big issue : Group , Output , Complete Signal Path , and Channel Settings + Mix Down to One Audio File
I think it deserves the award for the biggest issue found so far. Sorry but, holy s#%t !
2 Audio Tracks routed to Group. Group routed to No Bus.
1. Using Dry, Mix Down to One file is unavailable.
a) Trying to render a single event →
b) Trying to simultaneously render two events, one on track 1, one on track 2 → (two tracks produced)
Expected behaviour
2. Using Channel Settings, and Mix Down to One file.
a) Trying to render a single event →
b) Trying to render both events → Not doing anything
Inconsistent: My thoughts. It’s as if the “render-in-place brain” decides to switch back to the “Dry” Setting to complete the render for one event when it sees that no signal path forward is available. But in the case of two events, it doesn’t have a place to “mix” both tracks together, so it just refuses to do anything.
3. Using Complete Signal Path, and Mix Down to One file
a) Trying to render a single event → Nothing
b) Trying to render both events → Nothing
Expected. The signal never reaches Stereo Out. But if we consider the “complete signal path” from the signal’s perspective (Group 1), it’s unexpected.
4. Using Complete Signal Path, Group to No Bus, New Audio 3 channel with Group as Input
a) Trying to render a single event → Nothing
b) Trying to render both events → Nothing
c) Trying to render drawn event on track 3 (mix down to one file unavailable) → Produces empty (silent) render
d) Trying to render drawn event on track 3 with monitor enabled (mix down to one file unavailable) → Produces the correct render of tracks 1 &2.
See above for cases a), b). c) Expected. d) Unexpected?
A little pause here, because it’s time to go to bed. So far I don’t see something completely wild. The problems started when the group is output to the stereo out, at which point the render “brain” follows the signal both ways. To the stereo out directly from the group, AND through channel 3’s INPUT (which is the group), mistakenly so in my opinion.
I can’t find the words right now. If you do a regular export, do you see how the cursor moves in the background as if the project was really playing at a fast speed? Ok. Now imagine we had a tapemachine style monitor baked in, that didn’t need us to activate it. Any time the transport is stopped, we would listen to the INPUTS, right? Now, when wr render in place, the cursor doesn’t move like export does. So, it’s as if during render in place the INPUTS are left open and the signal spills through. I could be telling bullshit, but that’s the impression I’m getting.
Edit: The above is probably wrong. Because, if ALL the inputs were open, we wouldn’t get a render of the first two tracks, we would get silence. Moreover, when we perform this render, I think that the produced file doesn’t contain tracks 1&2 twice, the produced render is tracks 1&2 + track 3.
So, the needed explanation is: How does track 3 end up in the render?
If the logic is: follow all connections to the Stereo Out no matter what:
Track 1&2 → Group 1 → Stereo Out. Ok, obviously.
Track 3’s input is Group 1, so let’s render that signal path too.
In that case, the render should be 2 x Group 1. Once from the ordinary path, and another time from track 3’s input.
But this is not the case because: 1. We don’t get an increase in level (there’s no 2 x group1 in the render) and 2. Track 3’s events are in the render, so the input was never open.
So, my question now is:
If the signal of interest ends up in other tracks’ inputs, should it be followed there and rendered? (In my opinion, no.)
If it should, why doesn’t the track that receives the signal in its input flip the monitor switch so that the signal can get through? But instead renders what material’s on the track?
If it shouldn’t, why is the render brain tricked into following the signal to another, unselected track when a signal path for the original material to Stereo Out already exists?
Yet another edit:
I’ve been pondering about this. I’ve been reading the manual. There’s some ambiguity.
Starting with case 3 above, there’s two ways to look at things. Once we get to case 4, all hell breaks loose. Here’s the deal:
If we look at things from a signal path / mixconsole / channel perspective, failing to produce a render for a pair of channels connected to a group that connects to no bus makes sense. “You can’t hear it anyway when playing the project, right?”
But if we look at things from a data / arranger / track perspective, failing to produce a render for a pair of tracks connected to a group that connects to no bus doesn’t make sense. There’s clearly data there. A simple reallocation of the output makes the group audible.
So, how does render in place actually work? How does it see things? The manual chooses to use the word material for the entries on “render in place”, not helping the situation.
What does material mean? Is it a digital sum of the data, rendered in vacuum? Or the result of the data once it’s passed through the mixconsole, all routing included? But render in place clearly warns that it does NOT support sidechaining, so why does every routing path matter then?
You did some great observations, thank you so much for taking the time to do this !
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
Cheers and thanks again for taking the time to investigate
I agree, it’s a special case, and I think audio tracks being fed by groups should NOT be taken into account.
I don’t know about you, but using a group to feed an audio track I consider a trick that I do to get data (events) on a track. If a group track could hold events on the track for example, I would feed a group to another group instead, and not an audio track.
Sorry, I forgot to clearly say that even though I was talking about your initial setup, I had no events on track 3 at a time. I just drew an event, and tried to render.
Oh, by the way. Each of this tests? I was just pressing undo after each one, to go and try the next one. I don’t know if it matters or not, just saying it in case it matters.
Eh, who knows if some instability occurs removing all those tracks all the time. Since we’re in the twilight zone, I thought I’d better be completely clear!
I would never dream of such a setup (tbh, I didn’t even know you could rip events from different tracks…)
