Rendered in place track doesn't null

For some reason, rendered in place tracks would never null with the original source (unless this source is AUDIO track). I tried those synths, that are purely digital (Serum 2, Phase Plant 2). I used Sine wavetables. Just a sine. No effects. The rendered file was phase-inverted. And it never nulled. If I duplicate the track, then it nulls. I tried the same in other DAWs - FL Studio and Bitwig - and they null perfectly. I made a example project with the Retrolougue synth. Same issue. Here is the very small project. What is wrong? Why this render in place engine is so unreliable?

Null test Failed.zip (177.1 KB)

You must be really careful when doing null tests from synths, which might or might not contain randomization of whatever kind, even in a simple sine wave (a proper analog emulation of a sine wave is not nearly mathematical perfect), most of them have also free running oscillators.

Render the output of the synth first, then do another render in place. Be careful that you chose the same bit depth for render both times, and of course dry transfer.

I’ve done those tests with a rendered sine wave as an audio file, it nulls perfectly down to -infinity.

I know. But I know my synths very well. Those settings are very static and those are purely digital synths. Phase retriged. No filters. They will cancel each other when duplicated.

I did a test project with Retrolouge. It nulls when it is duplicated. I repeat, in Biwig and FL-Sudio it nulls to the rendered track as well. So synth will null with the rendered track. Not in Cubase!

Did you mange to create a rendered file that nulls to Retrologue (render in place, not export). Could you share the project, please? Or you only tried to null already two rendered files? I repeat, in all other DAWs, those synths will null to the rendered tracks (when they use static settings)

I don’t have Retrologue installed, and I would never trust these tests with any synth, simply too many unknowns in there. It might be they don’t cancel out, but I wouldn’t have the confidence in stating that it is necessarily a problem with Render in place, when there could be other factors involved.

But just for fun I tested it with sampler track and a sample of a sine wave, and the result was a perfect null.

Thanks. I will test a bit more. I will try to avoid synths these times. I will report if I find anything. Thank you for your time, fese!

I´m doing some tests and one thing I notice is that the rendered file is not perfectly aligned when zooming in:

I’m not sure about that yet. Need to test more. Maybe Retroloug is not a good example. Maybe it is still doing there something. I will find something more static.

But again, do you really know why that is? It might simply be something in the instrument, or some other setting. Test it with a sample audio file, even with non-timevariant effects on, if you like, or with the sampler track, as I did. No problem at all.

So it is entirely possible that the “issue” is with the third party plugin, if it is an issue at all, and not intended behaviour (which it could well be).

If I make 2 rendered files they do null between them, so I guess it´s not something of the instrument or randomization.

I did another project with The GrooveAgent SE. Same problem. I hope I can call GrooveAgent a static plugin? :slight_smile:

GrooveAgent null test.zip (1.3 MB)

Indeed. This is what is did too. I made two renders from the Groove agent. The renders DO null to each other. But they don’t null with the raw GrooveAgent. So thats exactly what I was thinking - VST instruments have timing issues in Cubase. That is the the problem. Those timing issues won’t be there after the final mixdown though. But why they are there in the first place?

Vsts synths modulate, so no render is ever going to be the same, its like playing the lottery, every time you play midi into a synth its modulating and calculating a different output, you have more chance of winning 10 lotteries in a row while being struck by lightning for the 7th time in a day than you do of capturing the same modulated sound from a vst synth.

This is why printing Audio is superior to leaving Midi blocks to keep commanding vst instruments to stop and start.

I suspect it’s just a question of the processing needed to get everything played in realtime that leads to some tiny delays in some notes….so the offline render is perfectly timed but the realtime doesn’t perfectly null to it….it’s also possibly system dependent. I can get most of that project nulling to inaudibility with only every third or fourth hit giving a little click.

Also note that that sample is not trimmed accurately in GA so if you look at the waveforms they will look late but so is the original.

1 Like

I tested that project here, and indeed, it didn’t null.

Then I created a new project (C14) here, inserted GrooveAgent SE, inserted that kick sample from your project without modifying anything on C1, added a MIDI event with that note, rendered in place, and it nulls perfectly.

edit: both track are routed in to Main, of course.

edit: I changed the amp envelope in GE, as you did, repeated the test, and also null.

Of course it might be the Cubase version, I am still on C14, did you do your test in C15?

Yeah, C15. Just try to make a 8 bar loop and loop it constantly. What would be the result? Will it snap at some point? Could you share that project, please?Thanks.

I wouldn’t bother with all that. But I have tested 3 DAWs. Only Cubase behaved that way.

Grim wrote: “can get most of that project nulling to inaudibility with only every third or fourth hit giving a little click.” - And I guess at random points! Right? That is not acceptable with the GrooveAgent just playing a sample. So it is not problem with the renders. Because if you do Two renders from GA SE, you will null them.

Personally, having worked for years with external midi and it’s many ms delays and jitter all over the place, a few samples drift only on playback doesn’t concern me too much.

It would be nice if it wasn’t there but it’s hardly a problem in realworld use.

Yep , did that, copied the MIDI event 8 times, rendered those 8 events (as one event and separate events), made sure that the MIDI parts were aligned correctly and that the MIDI event was exactly as long as the sample. Null.

What I discovered though is that if the MIDI event is shorter that the sample, and the audio then ends on a sample value unequal zero, then I got a click when the playhead reached the end of the last event of the row (but not before). But in that case, one should probably use fades anyway…

Whatever that is, it is still not a problem of render in place, because I checked the generated audio events, and they are identical, i.e. they null between each other, and no alignment problems/timing issues as far as I can see.
Maybe some playback issue with VSTis in certain edge cases, I don’t know. Certainly not something I will lose any sleep over…

What sample rate are you using? What is rendered audio quality? And what is Processing Precision bitdepth? Could you share the project please?

I did tests with 64bit FP everywhere. But i had the same problem with 32FP.

And no. Not some VST, it is GroveAgent doing that. A sampler. The most interested, that those disynchronizations are happening at random hits.

Here is another example. This time all defaults in Groove Agent SE. Another one is rendered. How do explain those random “snaps” and “bursts”? Make sure extract the zip older and just try to play from the archive.

GrooveAgent Default values null test.zip (1.1 MB)

I have sent all those examples to Steinberg support 25 days ago. But didn’t get any response from them. I don’t know how this works here at Steinberg. Bitwig and Fl-Studio teams usually responded in 2-3 days with a solution answer.