Feature request: FREEZE ALL SELECTED

I want to bump this topic here. http://www.cubase.net/phpbb2/viewtopic.php?p=943198&sid=4979f8bebdcf6f5056be11dbf889f76d

Freezing all instrument/Instrument Rack instruments with one click would be very helpful for saving CPU. Its a great feature that would save a lot of time, and it looks like several other users would appreciate it.

-10,000 Most professionals use slaves. :unamused:

ROFL. Most intelligent people like to save their CPU power. :wink:

I don’t see how.

Cubase would still take as much time to freeze the tracks as before.

The only saving you would get would be from not having to click 3 times.

  1. Selecting the track
  2. Clicking Freeze
  3. Clicking OK (assuming settings are correct)

Even then, the time it takes to do this can be mitigated via controllers or the keyboard and a good rhythm, or macros.

I suppose it would be useful, but there are ways around it.

And by using slaves they do. A slave is a computer connected via a network that runs the VSTs on itself, thus saving CPU power on the main DAW.

But what if i have 100 tracks i have to do this on? The actual freezing itself takes time, so it would be convenient to freeze them all at once, get a cup of coffee and cme back after the freezing/unfreezing is complete. If there is a keycommand for freeze, i might be able to do a macro. Ill look into that

In what situation would you have THAT many tracks?

Fair point.

I don’t know about a key command, but the CMC-CH has a freeze button. So it should be able to be set up as a MIDI controlled function at least.

It does save you time in the sense that you’re not stuck in front of a computer waiting for the freeze operation to be done before you’re able to do it again for the next track(s). And if Steinberg can include a time estimate of how long it would take to freeze several tracks, even better. I’ve always wanted this feature, even before switching to Cubase.

Who needs freeze? Check you’re not using it just because it’s THERE.
If your computer’s less than three years old and you use less than 200 VSTi tracks and don’t need reverence as an insert on all of them you probably don’t need it.

PS. I am exaggerating somewhat.

FYI here are my basic specs, and Im not looking to upgrade my system anymore at this time.

i7 920 24GB RAM OCZ Revodrive for samples, RME HDSPe AIO.

Furthermore i have a specialized reason to need more CPU. Due to an error with EWQL Play engine, pops are being added to offline exports in Cubase. Until EWQL resolves the issue I have perform realtime bounces which are incredibly demanding on CPU. instead of batch exporting hundreds of tracks to sace CPU, it would be convenient to be able to run the whole project in real time without an overload, and freeze all tracks is a quick way to do that

To make it even more frustrating, raising the buffer size is not an option. If i go any higher i get stuck notes and poor midi timing. So, that is why i need freeze, in a nutshell.

Don’t freeze. Just convert the tracks to audio from the off. Then export to your hearts content. Looks like freeze is getting in your way so take it out of the equasion.

Why can’t frozen tracks be soloed or muted?

Because it is only meant as a stopgap and not a feature (because freezing is almost obsolete and was only ever meant for a short lifespan) the functionality is limited.
It was only ever put in because Logic had it and they were pestered for it’s inclusion by certain very few posters who had the time to post all day and who continually moaned that it was not fully functional when they got it.

A fully functioning freeze is pretty contradictory anyway as it is there to SAVE resources and NOT use more.
Like complaining you can’t drink a cup of ice. :mrgreen:

Frozen is frozen. It’s GOT to have some limitations. I’m not a doctor so if anyone still doesn’t understand that, I can’t do anything more for them and neither can Cubase. :mrgreen:

by certain very few posters who had the time to post all day

:laughing: :laughing: :laughing: :laughing: :laughing: :laughing:

Oh Conman, you make me SO happy with your posts! hahahaha!


I bet you don’t use any heavy sample libraries, like EWQL Hollywood Strings or VSL, do you? Otherwise, you wouldn’t be saying the things you say. Seriously dude, just because a feature doesn’t apply to you doesn’t mean others don’t need it. Maybe some of us have bigger demands on our systems and/or don’t have newer systems that can handle the load we put on them and thus we require features like freezing in order to get the job done. A little improvement in that area wouldn’t hurt you, would it? It certainly wouldn’t change anything for you since you don’t use freeze, so why be against it?

NOTE: [all the above are rhetorical questions. I’m not interested in your response, cause they’re hardly ever worth reading anyway].

Which version of PLAY do you have? Which libraries do you use? Are there any step you could provide to reproduce the problem? I personally haven’t ran into this issue. Everything bounces just fine here.

Oh dudydudydudydude. Some of us know the system limitations and especially wallet limitations and don’t go buying unusable huge libraries without first being able to afford much more grunt in the way of a LARGER computer array.
If you’ve bought more than your little system can handle what’s the point of blaming it on the software maker?

If you can afford large libraries you are surely professional enough to know these things. If you aren’t you have no place telling anyone else they don’t know what they’re about.

You need freeze because you’re in a bedroom and not in a $500000 studio. Right? If you’re in a bedroom what’s the point of EWQL etc? And if you’re in the great studio you’ll have the bucks not to need freeze. Simple fact of life.
Sortware or hardware orchestras are expensive, not just money expensive. Neither will fit into a bedroom.

All the above are rhetorical answers because I know you’re not reading this right now. :laughing:

No, conman, with current EWQL Libraries its not always practical to spend thousands of dollars on computer hardware that may or may not solve the issue I’m having. EWQL’s own computer test system isn’t all that much more powerful than my own. Instead, EWQL/Steinberg could fix their offline bounce flaws and I wouldnt have the impractical demands of bouncing 100 tracks in real time.

Freeze all selected is a simple feature to be added, so I don’t see why steinberg would debate. Just some basic macro programming that Steinberg does so well on hundreds of other features, but occasionally they forget to include it on certain features for some reason.

I have a 5 minute cue with 100 tracks. realtime export takes at least 5 minutes per track. 100 tracks x 5 minutes = 500 = 8.3 hours. I’m not looking forward to spending 8.3 hours to render this stupid project.

So I’ll probably have to use freeze, it just would be a lot quicker with an automated macro, thats all.

There’s no debate from the company, in fact it would require fundamental re-design to incorporate even the basics of a fully frozen DAW software.

Cubase Ice version? :laughing: