Why does render-in-place "Channel settings" Processing option include the fader position?

All I want to do is use render in place to be able to offload the VSTi and VST inserts I’m using. But because the “Channel settings” Processing option includes the fader position, it always gainstages the track wrong, and I lose information. A track I happen to have on a fader at -15db will be rendered 15db quieter.

So now, every time, I have to remember the current fader position, set the fader to 0db, save, render in place, then set the new track to the old fader position, just not to sabotage the gain of the track. This choice from Steinberg makes no sense.

1 Like

Are you saying that, if you use the Dry option in the render settings, it still applies the fader? That doesn’t seem right. (I do know that it applies the fader if I use the Channel Settings, which is what I typically done as I’d generally wanted inserts to be included on my old computer and I was separating out “to tape” processing from later “mix” processing that would be done on the rendered track), though I also use the workaround you mention if I don’t want the fader setting applied.)

No, I want to use the “Channel settings” Processing option. The “Dry” one doesn’t accomplish anything, what would be the point?

Since you also have to do the same laborious workaround as me, I feel vindicated in my bewilderment at Steinberg’s choice here.

Yep pre fade would be a useful option.

If you read the documentation it makes sense. From what I can tell using “Channel Settings” includes “insert effects, channel strip settings, group channel settings, and FX send channel settings”.

Therefore, if you have your sends post-fader the fader value has to be taken into account in the render.

I think rather than the fader being included you probably just need a setting that is somewhat between “Dry” and “Channel Settings”, correct? The insert-chain before the fader, right?

That’s the “Complete Signal Path” processing option. Hovering over the option in Cubase right now, the tooltip for “Channel Settings” says “Rendered files include insert effect, EQ, and channel strip settings.”

Whereas:

Read the manual. I copied from Nuendo’s manual but it should be the same. I don’t care what the pop-up description says, I care about what the manual says and what the function does.

I tested it. It does what the manual says it does. It renders with the insert effects in the signal chain and it includes FX tracks. Like I said, if the FX tracks are included in the render and the sends to them are post-fader then it makes total sense for the fader’s level to be included. Anything else would be “worse”.

I think you should search for a feature request for what you’re looking for and if it exists see what the response is and maybe bump that thread. If such a thread doesn’t exist start one with the “feature request” tag.

1 Like

Interesting. I see the documentation does say this, but that had not been my previous understanding of this option, which had been that it just includes inserts and channel strip settings. Also, it does transfer settings like routing, which wouldn’t seem to make sense if it were including send effects and effects in downstream group channels, which the documentation’s text seems to imply.

1 Like

yeha you have a good point.

As a workaround you can disable the read automation for volume lane before rendering and then copy the automation lane from original track to rendered one and I guess you could do a macro for all these.

But of course I´d be better to have a check mark in the rendering menu.

Another way is: after rendering with the read volume lane disabled, duplicate the original track, remove data (the automation remains) and insert the rendered audio into that track. I´ve checked it and it works.

You also don’t have to reply to this thread!

Anyway, like @rickpaul attests, the “Channel Settings” option doesn’t bake the FX sends, it transfers them. So not only are the tooltips and manual out of sync, the fader behavior makes no sense for what it actually does.

I didn’t write that to criticize you or disagree with your fundamental goal or request, I just meant that when I try to understand how a DAW works I look to the longer, more complete manual for the definite word. It should always have the most complete and correct description of any function. So it was not a criticism of you or what you’re looking to accomplish.

I just shared what I thought was correct technically, not to debate, just to make sure you were aware of it. And on that note:

I tried it like 10-20 minutes ago by sending a signal and as you say the send is copied, and the FX is not exported with the file. I was probably “misled” because the inserts are not transferred - which I noted - but I didn’t keep an eye on the sends.

So to me it seems like not only are you right but the manual is dead-wrong. Unless I’m missing something (again).

If you start a thread regarding the wording of the manual and/or the feature request you’ll for sure have my vote.

3 Likes

Cheers and thank you @MattiasNYC

Actually, just thinking about this some more, it may make more sense. In particular, to the degree I have sends in tracks I am rendering to audio, they would be post-fader. Thus, if the fader on the new track is set to 0 dBFS, but the fader output is not included in the rendered audio track, the level of signal going to the FX tracks through the sends would be different than in the original instrument plus inserts track (assuming the send levels were maintained). Of course, a reasonable thing might be to just set the fader of the rendered track to the same level as the original track, but maybe there is some other consideration I’m missing.

Mind you, my normal use case for this has typically been for tracks with no sends configured – I’ve basically been using it like what might have been rendered to tape in a totally hardware-based studio (so basically virtual instruments, amp/preamp simulation if needed, any studio environment simulation, tape emulation), doing my mixing, including adding sends, on the rendered track later. I don’t know if I’ll end up doing that on my newer, more powerful system, though I’ve also been finding there are some workflow benefits to this approach (relating to reducing decisions at mix time).

Yeah this is what I want

1 Like