freezing and bouncing

[philbrown]

As far as I can tell, freezing is just bouncing and then disabling the original the original track(s), and unfreezing is basically undoing the bounce and enabling the original track(s). Is there some other diference I'm missing? Just curious.

[buzzsmith]

This is not really an answer to your question but it may help others.

Freezing is real time and bouncing is much faster.

If I have 5 VI drum tracks in a 4 minute song, freezing each track would take about 20 minutes total for the 5 tracks. With bouncing, total time is around 5 minutes.

Buzzy




Sent from my iPad using Tapatalk

[MIDI Life Crisis]

Hang on while the chorus against bouncing chimes in. I bounce 99% of the time. I NEVER bounce when there is a complex VI at work. Complex in the sense that it is highly scripted and/or a very large VI (in terms of the number of samples being triggered). In fact, I will sometimes bounce the simple sequence parts in one pass and then do a separate realtime (freeze) on the complex VIs. Otherwise, I will hear lots of dropouts, clicks, pops, farts, etc. OK, maybe the farts are from a difference sauce [sic] butt you get my drift, so to speak.

[Tritonemusic]

Freezing is real time and bouncing is much faster.

While that is generally true, BTD can actually take longer than realtime. I've had projects that were so CPU-intensive, they'd play back with popping noises, stuttering, etc. However, BTD would render the final perfectly, even though it would take longer than Freezing would because DP was taking time with its computations to make everything error-free.

Just thought I'd mention it.

I haven't had a project like that in a long time, fortunately.

[MIDI Life Crisis]

Freezing is real time and bouncing is much faster.

While that is generally true, BTD can actually take longer than realtime. I've had projects that were so CPU-intensive, they'd play back with popping noises, stuttering, etc. However, BTD would render the final perfectly, even though it would take longer than Freezing would because DP was taking time with its computations to make everything error-free.

Just thought I'd mention it.

I haven't had a project like that in a long time, fortunately.

Interesting, but true! I've also seen that in some of my longer works (some easily over two hours). Realtime will be faster. Since moving to the 8-core and now the trash can, BTD is often a no-wait situation, especially going to an MP3. Bouncing to project format is always quickest of all. If a conversion to another format has to happen, that can really slow things down.

[FMiguelez]

As far as I can tell, freezing is just bouncing and then disabling the original the original track(s), and unfreezing is basically undoing the bounce and enabling the original track(s). Is there some other diference I'm missing? Just curious.

The most important distinction is that Freeze works at the track level i.e, it won't include anything from its sends or any automation "further down" in aux subgroups in the busing chain.
Bounce, OTOH, is global and will include everything that is routed to the main out, and is play-enabled, including FXs.

[philbrown]

The most important distinction is that Freeze works at the track level i.e, it won't include anything from its sends or any automation "further down" in aux subgroups in the busing chain.
Bounce, OTOH, is global and will include everything that is routed to the main out, and is play-enabled, including FXs.

That is good info, thanks, FM.

[Michael Canavan]

Bounce is near impossible to get more than stereo or surround audio files out of though.
I freeze to flatten all tracks to audio, since DP doesn't have that function.

I suppose what with how you have to create aux's at least in your Sequence/Chunk to freeze a V-Racked instrument etc. track, I get why MOTU don't offer a "Bounce all tracks as separate audio Files" type command, but I still think they should. It's a complete circus to render all tracks to audio in DP compared to Live, Logic, Cubase, etc. etc.

[MIDI Life Crisis]

"Bounce all tracks as separate audio Files"

+1 and add CHUNK Folders to that, please. Hold the pickle (so to speak).

[FMiguelez]

Bounce is near impossible to get more than stereo or surround audio files out of though.
I freeze to flatten all tracks to audio, since DP doesn't have that function.

I suppose what with how you have to create aux's at least in your Sequence/Chunk to freeze a V-Racked instrument etc. track, I get why MOTU don't offer a "Bounce all tracks as separate audio Files" type command, but I still think they should. It's a complete circus to render all tracks to audio in DP compared to Live, Logic, Cubase, etc. etc.

Agreed.

In the mean time, and depending on how much you do this kind of thing, it might be better to simply put Melda's Recorder plug-in in every track that you want to freeze. It will do just that: record the output of whatever track you put it to, and you can specify its propeties quickly in the dialog box.
Oh, and did I mention it's free?

https://www.meldaproduction.com/MRecorder

[bayswater]

It's a complete circus to render all tracks to audio in DP compared to Live, Logic, Cubase, etc. etc.

For that reason i usually set up the sequence right from the start so it can record to audio tracks in one pass.

[terrybritton]

It's a complete circus to render all tracks to audio in DP compared to Live, Logic, Cubase, etc. etc.

For that reason i usually set up the sequence right from the start so it can record to audio tracks in one pass.

Just a question concerning that, since that has always been my approach as well.

Doesn't the new system since 9.1 get forced into real-time mode when you record into AUX tracks? So, it cannot take advantage of the pre-rendering engine? (Or, is that a good thing?)

I've been wondering what the best approach should be with this new engine.

Terry

[Michael Canavan]

It's a complete circus to render all tracks to audio in DP compared to Live, Logic, Cubase, etc. etc.

For that reason i usually set up the sequence right from the start so it can record to audio tracks in one pass.

Just a question concerning that, since that has always been my approach as well.

Doesn't the new system since 9.1 get forced into real-time mode when you record into AUX tracks? So, it cannot take advantage of the pre-rendering engine? (Or, is that a good thing?)

I've been wondering what the best approach should be with this new engine.

Terry

You should be able to test that really pretty easily. I'm not sure how you guys are doing this but say you have V-Racked instruments and in your final MIDI/audio sequence you have Aux busses for all tracks. The Instruments can be assigned to the bus or to master out, doing both and registering the CPU difference would answer this. Plus all that VS opening all plug in Windows will 100% let you know if simply running a virtual instrument to a bus in you open sequence will stop pre-rendering.

Just the fact that you can send via bus the V-Racked instrument to an Aux or an audio track, or you can do what I often do, and drag the V-Rack into the Sequence/Chunk, then freeze... basically once virtual instruments became the norm, DP got complicated.

[bayswater]

It's a complete circus to render all tracks to audio in DP compared to Live, Logic, Cubase, etc. etc.

For that reason i usually set up the sequence right from the start so it can record to audio tracks in one pass.

Just a question concerning that, since that has always been my approach as well.

Doesn't the new system since 9.1 get forced into real-time mode when you record into AUX tracks? So, it cannot take advantage of the pre-rendering engine? (Or, is that a good thing?)

I've been wondering what the best approach should be with this new engine.

Terry

I don't use aux tracks for this. I route to audio tracks with monitoring on. It's a bit simpler. If an Aux is required in the signal path, I suppose its output would not be prerendered but this all works fine for me in 9.13.