Freeze or Render?

[metamorphosis]

And we all love a good one-button affair...

I know i do

[mchannemann]

Regarding
DWS:
Regarding the new Render Track option in the update (variable bit depth and sample rate), does 'Freeze Track' render at the highest available bit depth (since there are no options available for Freeze Track?)
It always depends on the selected recording depth for the song,
the daw always records all audio files in the same bit depth, internally the mixing is only always 32/48/64 bit depending on the daw
regards,
Thor

[metamorphosis]

Regarding
DWS:
Regarding the new Render Track option in the update (variable bit depth and sample rate), does 'Freeze Track' render at the highest available bit depth (since there are no options available for Freeze Track?)
It always depends on the selected recording depth for the song,
the daw always records all audio files in the same bit depth, internally the mixing is only always 32/48/64 bit depending on the daw
regards,
Thor

To answer this more precisely: because tracktion or any other daw has to feed the frozen signal back into the audio chain at the end of the day, it makes most sense, cpu-wise, to make the bit-depth of the frozen signal the same as the internal audio chain (in the case of tracktion 32-bit, unless you have the higher-cpu-cost 64-bit internal processing turned on).
Implementing a freeze function with a lower bit depth would create more cpu-usage rather than less. It also makes it much easier to implement a freeze function, given that all you're doing is running those tracks through the standard bus and re-routing their output to a given file, rather than the audio-playback routines.
Cheers-
M@

[DWS]

given that all you're doing is running those tracks through the standard bus and re-routing their output to a given file, rather than the audio-playback routines.

So 'freeze' won't run into the same rendering issues/problems reported on the forum for 'render'?

[IIRs]

what issues?

[DWS]

what issues?

This was from a discussion awhile back, maybe it's been fixed?

http://www.kvraudio.com/forum/viewtopic ... everb+tail

[IIRs]

That was fixed ages ago

[DWS]

That was fixed ages ago

OK, thanks! So you are confident that freezing tracks and then rendering/export to 24 bit WAV will yield the same results as say using Tape It to capture un-frozen tracks?

Not that I can hear the difference but I lost a bit of confidence in Traction's render/export after this issue and others such as "pitch shifted clips not rendering properly" came to light (I see that has been fixed also

[Lunch Money]

Holy moly... render issues have been fixed for a dog's age.

In Tracktion, multiple frozen tracks become one file. So let's say you have 10 tracks frozen into 1, and then 5 unfrozen tracks. That'd be different than mixing 5 rendered individual tracks and 5 untouched tracks. So, to use the TapeIt comparison, it'd be more accurate to compare rendering 5 different tracks before mixdown.

To MY ears, the freeze way of doing it would still be fine.... but it's not really something I'd do anyhow. I'd be more likely to use render before mixdown (on intensive tracks) if my project is a resource hog.

Greg

[pdxindy]

I, too, would like to have a per-track freeze option. While the current freeze pool works well to save disk/CPU resources it's kind of a pain if you just want to unfreeze one track out of 20 frozen tracks because it has to again render the other 19 tracks. Sure, you can "render track -> add rendered tracks" but this leaves you with an audio file in your directory and you still have to manually mute the track or disable the VSTs -- not a very elegant solution for so elegant a program. I would like to see a freeze command with two options: Freeze-to-pool or freeze-to-individual-file. The freeze-to-individual-file would perform the same function as "render track->add rendered tracks->mute/disable VSTs" but would be a one-button affair and one-button to undo.

try freezing 10 tracks on a 15 minute composition... there is enough time to go get lunch...

I enthusiastically add my vote for your suggested freeze option. It would be a lot more elegant. Besides having to mute track, you have to keep track of which renders go with which tracks, and if you are not organized like me, it is especially hard to remember if you open up the project a week later.

I do not like using render to freeze a track. It does not work well for me.

[Lunch Money]

I DO think that the current implementation is the best solution for resources, but for elegance I think a per-track option is well-needed.

I use render, but there are just a few 'housekeeping' issues that could be added or switched around to make it as easy as "freeze"...

A simple freeze dialogue could be:

- Freeze to individual track
- Freeze to group

Freeze to track would enable you to then adjust pan/volume, or add additional effects.

Freeze to group would be the current implementation as a separate ".freeze" file. Perhaps it could even be branchable:

- Freeze individual track
- Freeze to group ->

Then from freeze to group there would be:

--> create new group
--> group 1 (if it's already created)
--> group 2 (again, if it's already created)

In writing, it sounds cumbersome, but in practice it would be smooth and easy. Plus with "freeze to individual track" as a shortcut key, you wouldn't even need to navigate menus.

Best of all worlds, no? As scalable as you want it to be. You can mix and match individual frozen tracks, groups, or just use one fat 'group' to emulate the current implementation of the freeze function.

-----------

An important distinction between this and render comes down to nothing more complicated than the 'un-freezing' process. When you unfreeze, it'll take care of housekeeping duties for you, cleaning up the 'rendered' (frozen) files, restoring your original plug-ins, and all that stuff. The current way of doing it (muting the original track and hiding it) is cumbersome at best... resizing all tracks un-hides it, and muted VSTs still occupy RAM even if they don't use CPU.

The term "freeze" really just refers to a series of rendering shortcuts. I just think that certain changes made could streamline the current way of "rendering" individual tracks or groups.

Greg

[mandolarian]

and if you are not organized like me, it is especially hard to remember if you open up the project a week later.

I have trouble remembering a week later that I had a project to open.

I think in T3 there should be an option for it to PM you at Kvr and nag you to finish a project.

[IIRs]

[metamorphosis]

I DO think that the current implementation is the best solution for resources, but for elegance I think a per-track option is well-needed.

I use render, but there are just a few 'housekeeping' issues that could be added or switched around to make it as easy as "freeze"...

A simple freeze dialogue could be:

- Freeze to individual track
- Freeze to group

Freeze to track would enable you to then adjust pan/volume, or add additional effects.

Freeze to group would be the current implementation as a separate ".freeze" file. Perhaps it could even be branchable:

- Freeze individual track
In writing, it sounds cumbersome, but in practice it would be smooth and easy. Plus with "freeze to individual track" as a shortcut key, you wouldn't even need to navigate menus.

Yay I'm glad other people agree with this idea-
I don't see the point in multi-groups though- what additional functionality would that provide?
I think - in the interests of keeping everything as simple as is humanly possible - 1 group -may- be enough - but Lunch Money, do elaborate on what you see as the benefits of multi-groups-
Yay!
m@

[Lunch Money]

Easy! Let's say you like the resource-saving ability of the big group freeze, but you don't want to re-freeze all 10 of your currently-frozen tracks again. It's still enough of a savings for you to begin a new big 'freeze group' so that you end up with 2 or 3 batches of 10 instead of just one. It'd make re-freeze time much quicker in many situations.

That, and if there's already the choice between 'group' and 'individual', the code's already going to be in place. Might as well add the most possible flexibility to it.

Greg