Multiple Track Freeze (Unfreeze) [Achieved]

STILL waiting for this.

Pro Tools has the best implementation of this currently, but all other major DAWs have had this feature for a long time now.
Can we get caught up please?

It would be lovely to have some of these long-requested features ahead of new plugins.


(At the very least can the freeze function be made key-command assignable?)

This should be a task for PLE I think, in which a user could utilize this in a number of different cool ways (like finding/selecting all tracks that have inserts in the project and then freezing them)

See more details here

Having Freeze recognition in PLE would be great as well, but there’s just no reason at this point we shouldn’t have a main-level way of freezing multiple tracks at once.

Ideally:
-Select the tracks you want to freeze
-hold Shift-Opt (quick link) and click the freeze button on one of the tracks.

Unfreezing should work in the same manner.

it could be both

absolutely. In a perfect world we would have

-Multifreeze/Unfreeze using Shift-Opt
-PLE access to Freeze/Unfreeze condition
-Key Command access to Freeze/Unfreeze

I always though ‘Render Freeze To TrackVersion’ could make sense, or even if the entire protocol changed to that… because I can’t really see a reason not to… and then also that way, the “Freeze” can be edited. It’s pretty much the exact same thing, except you’d actually be able to edit the freeze.

The only issue actually, is I find TrackVersions can be a bit finicky at times if you are doing multiple channels to the same ID, and then doing one channel - it makes things confusing. which is probably why ‘Freeze’ wouldn’t work for TrackVersions.

edit

I mean, if it did work that way with trackversions, and you were freezing a track that had the same ID as multiple others, it would just have to prompt-ask you whether you want to do the other channels as well - which, it wouldn’t be a big deal to in this new protocol.

Yep! This is useful in pro tools. Pro Tools has always been good at applying a function across many aspects of the app consistently… ie changing or cascading io, applying EA to multiple tracks at once, etc so of course that included freeze. I think I other devs would do well to take this approach too! And always work to keep functions consistent across similar actions.

+1 for mulitple track freeze and unfreeze, with shortcuts

+1

+1

+1

+1 for multiple track freeze/unfreeze based on selected tracks and either a context-menu that gives freeze as an option or a modifier key on the freeze button of one of the tracks in the selection (e.g. Ctrl-Freeze). I’m used to having this in Cakewalk/SONAR, and it’s a huge timesaver when needing to freeze/unfreeze multiple tracks. Also taking a lesson from Cakewalk/SONAR would be if the freeze options could be separated out from the freeze operation – they use a right click on the freeze button to change the freeze options, so it saves time on each freeze operation since you only have to click an extra “ok” button when you want to change the options, not for ever freeze operation (it just uses the options already set when you just want to freeze one or more tracks).

+1

And this should include "Automatic Tail Size Detection"

Different tracks have different tail sizes (e.g. reverb), and one don’t want the audio to be cut off on some tracks.
Also “Render-in-place” should include “Automatic tail size detection”.

I found this request at Youtube channel “Vintique Sound”. He also brings up Multiple Track Freeze and some other good feature requests:

Alternatively, there is also a simpler approach:
just add the ability to add an additional automatical fade-out section at the end of the tail.

The problem with tails being cut off might be the reason this has not been implemented so far? But this is possible to solve.

While that could be useful, I wouldn’t really see it as critical. Two specific thoughts on why I say that:

First, it would be possible to do something like set one set of freeze parameters, do a batch freeze for tracks with similar characteristics, set another set of parameters, do another batch, etc. And it is often the case that tail size isn’t such a big issue on freezing tracks anyway, so something like 5 seconds (which I believe is the Cubase default) will be (more than) enough for many types of tracks. The main exceptions will be synth sounds with long decays (as opposed to acoustic tracks), or if you’re putting a long reverb (and/or delay with feedback) in an insert and freezing the inserts in addition to a virtual instrument (or freezing an audio track with a reverb on an insert).

Second, another possibility would be to do something like “detect silence”, where the freeze file gets truncated after the waveform goes below some threshold for a certain amount of time. (Cakewalk has a similar feature when freezing tracks that allows cutting a long track into shorter clips. It’s worth noting, though, that Cakewalk’s freeze is different from Cubase’s in that Cakewalk shows audio clips after a freeze, whereas Cubase still shows a MIDI clips, albeit locked ones, with the underlying audio being totally behind the scenes.)

Either or both of these possibilities could help get around needing to have Cubase need to “figure out” tail size for each track (though the second option is sort of doing that, albeit based on simpler parameters than some generic “figure out tail size” that doesn’t have an explicit threshold or length of time associated with determining the tail has finished).

Rick

Sure, but it would be much better if it could be done all automatically in one single go, instead of a manual repeated process. That’s exactly what we want to get rid of… (even if it would take a batch at a time, instead of only one track at a time).

Well, that’s basically what I mean with “Automatic Tail Size Detection” - detect when the tail ends, thus becomes silent.

I wrote something about that in the thread I linked to:

when the rendering process reaches the tail section, it does some kind of measurement of the audio level. And when that drops below a certain threshold value, it applies an automatic fade-out to zero (instead of an abrupt stop/cut-off).
There could be an option for the threshold value, and the fade-out length.

Check my suggestions for auto freeze Track freeze intelligent management - Cubase - Steinberg Forums

+1
i mixed project in protools with 20 back vocals with plugins on each vocal track. i could freeze/unfreeze them all in one go even from the mixer menu

My reason for suggesting that I didn’t see this as critical was not to discount the usefulness of being able to do all selected tracks in one operation. Rather, it was to say that I didn’t see the automatic tail size detection as being critical to having a batch freeze/unfreeze operation. That is, having the batch freeze operation without the automatic tail size detection would be preferable to not having a batch freeze operation at all.

In practice, at least for my types of projects, the default 5 second tail size would suffice for most of my projects. It is rare for me to need to override that, and, when I do, it is for a predictable set of tracks within the project, such as synth pads, which are likely all in a single folder, so it would be easy to freeze everything in two batch operations – i.e. one for the synth pads and one for everything else – or even to set the tail options to the longer needed values and make it one operation, with the expense of maybe 10 seconds of extra tail size than what would be needed on tracks other than the pads. And the slightly larger freeze files would be a relatively minor cost unless there were many tracks that didn’t need the extra length.

Sorry, I hadn’t checked out the link, so was just going by what was in the post. And, again, my point was not to discount the suggestion, but rather to suggest that the automatic tail size detection shouldn’t be critical to implementing a batch freeze/unfreeze capability, especially if it meant the difference between having that facility or not having it. Having to manually set tail size prior to a batch operation would be a very minor workflow slowdown compared to what we now have in needing to freeze each track individually, then unfreeze each one individually at the time of needing to make changes.

Cakewalk (formerly SONAR) has had this sort of batch freeze/unfreeze for ages now, and it works great in practice. While I’ve made Cubase my main DAW for new projects for other workflow-related reasons now, this is one area that was/is a big step backward, not only on the individual track freezing, but also on having to respond to the dialog box to set freeze options on every freeze operation (as opposed to only needing to change the options if I need to for a specific freeze or batch of freezes).

Rick

+1