Bounce v. Freeze v. Realtime: What's the skinny?

[FMiguelez]

And what about Tempo, guys?

There are some VIs that simply get out of whack during the bounce when there are tempo changes. The more there are the worse they get.
And this happens also when freezing.

The first example that comes to mind is some of Steinberg's stuff. VG2 was a typical case. ANY time I freezed or bounced, there were all kinds of problems with these instruments because of the tempo changes.

[MIDI Life Crisis]

Nope. Even in files with no tempo changes, I would get (and sometimes still get) odd artifacts. I've traacked down about 90% of them to data, but the other odd 10% or so are so dang elusive and they don't always happen in the same place.

[Frodo]

IF there is tempo info in the Conductor Track, it's important that the CT be included in the track selection--- at least in my experience. In some cases (in previous versions of DP) a project benefits from having a Master Fader track even though one *can* bounce or render a stereo master track without a Master Fader track. I never figured out why, but I recall a few people verifying greater success with a Master Fader track than without.

This was, of course, for those quickie mixes and not for projects in which intensive mastering fx were required on a Master Fader.

Frodo said ..."It's just that now I want to do a three-way shoot-out on Bounce/Freeze/RT in the same project just to *see* what's up."

Will be most excited to hear your results!!! Ours tests here indicate that we should not bounce at all, but freeze is great over 90% of the time, and prints in realtime are always correct. But we use tons of trks and VEPro slaves etc so that must be taken in to consideration with our results.

Uh-oh. Now, I've got serious homework to do. LOL!

Then again, real time has always been reliable, to say the very least. In a lot of cases, users have long proclaimed greater satisfaction with RT over bouncing and freezing. Yet, other users have had no complaints with any of the three methods. Hmm.

Yet, I did a project in January which I was happy with at the time. Upon a recent review of the bounced mix (which no one else had to hear) I found that I was not as happy with it in retrospect. I'm not sure whether it was a matter of false optimism or a matter of the bouncing process, but the difference was unmistakable.

Must investigate and will report back.

I should also say that I'm not running any "bridges" at the moment. All instruments and fx are 64-bit. That is to say that I couldn't report any results that involve 32-bit blocks being run within the 64-bit kernel.

[zandurian]

I've thought of that too because it's so strange... BTD, being an offline process, should be able to use any and all CPU resources as needed. There's nothing else going on other than the bounce process.

I mean, nobody is "rushing" DP to do the bounce... it could take as long as it needs as long as it is ensured that no artifacts will result for lack of processing power.
Shouldn't it take as much CPU and time as necessary?

Exactly. If it plays right in real time a bounce should simply print it to audio accurately and as fast as the processor allows. All else is software bugs.

[MIDI Life Crisis]

Of course. Couldn't possibly be an artifact of the OS structure... Nah. It's always the software.

Maybe. Maybe not. Out of my area of expertise.

[cloudsplitter]

I always have a master fader track..!!
As far as limiters go..isnt it standard that they have a look ahead function..?