Hi,
I just learned how Cubase freezes instrument tracks and I like all the choices available.
One thing I can’t figure out is how,if you are totally satisfied with the instrument track, you can permanently convert the contents to audio.
I like to do this at some point in a projects life so that I have a “portable” archive of audio tracks that are independent of instruments and such.
I am bit confused about where Cubase hides the renders it uses for the instrument freezes and how to import the audio tracks as replacements for the instrument tracks. I typically “save as” my projects as they progress so I’ll always have a .cpr to go back to in case I decide I need too, but I’d also like to be able to assemble a project of just audio files as I near completion of a project.
What you want to do is FILE>EXPORT>AUDIO MIXDOWN.
On the dialog, at top left, switch to “batch export” and select the instruments you want to bounce. At bottom under “import to project” choose “audio track” (“Pool” will auto select).
This will export any selected tracks, within the locator region, including any inserts and fader settings.
Use the naming conventions however you’d like to best be able to identify the tracks (this is where logical track naming shows its benefits!)
After its done, you’ll have each instrument bounced to separate audio tracks. After making sure they sound how you like, you can delete the original VSTi tracks.
Batch exports bypass the Master Bus and any Groups (but you can do a separate bounce of any of those!). Which makes sense—it prints just what involves that track.
Yeah, The manual is a strange beast. TMI in some sections, and some new features not even included! LOL
But still: the reason why nobody reads it, is because it only states things that people can find on their own most of the times.
Everybody can figure how to click a button.
Ok, it should be told to click it, but the reason why is the essence.
And things like this f.e.: to get some insight and reasoning of why freezing is essential and how it can improve the workflow, should be something that is included in a manual imho.
At least this is something we do at our company.
We tell people why (and how) they are doing it.
To be a really useful manual, it would probably need to be about three times as large, which I imagine would be even more of a disincentive to use it.
However, I do recommend that new users read at least the first paragraph of every chapter and section to at least be familiar with what Cubase can do. Otherwise, in their ignorance, they may just work out a ‘long’ way of doing something and think that’s just the way it’s done.
I would suggest to split it up in to even more readable sections then they do have now.
a reference section, shortly explaining the functions as they do know
a production examples that cover the basic workflow
and the sections they do have now for the rest
Production examples shouldn’t replace 3th party in depth coverage, but give creative ideas for using the software.
Coverage as: why the mediabay and how to use it, working with templates, a big part covering ASIO performance versus computer performance and how to deal with it (they had this in the past), to freeze or not to freeze, exporting your production, a basic section of mastering a track, audio editing and vari audio: how to handle, midi processing, …
A very fine example of extensive coverage of this is the omnisphere GUI. (only for the preset level)
They state how the sound is made and where some of the usage tricks are. That is a big ++ imo.
WIth the new GUI possibilities that exist you can make full usage of the screen and even multiple screens for a GUI, so it is possible to give it some space.
A lot is also covered with video’s on the web, i know, but as with everything on the web, it’s quickly a complete overload on info scattered around on several sites, and not everything is of very high grade, certainly not those voice comments.
Maybe i am oldscool on this, but for me a written manual is still the best thing to get insight because i can read it a my own tempo.
+1 You know, the best thing about written manuals is that you can put it in your magazine rack in the loo. Within a few months you’ll have read the whole thing, front-to-back!
??
OP was not talking about bounce in place. He was talking about the frozen audio renderings that are not directly accessible in the pool and the answer is given higher in the topic, and that can be done in several ways.
If you mean this:
This is something you do with a group track in your project.
In cubase in fact, if you want, you do not even have to bounce a thing, but if you want you can render your vsti directly into audio without having to bounce around. Again… if you want.
How? Connect the output of the vst to the group track.
Assign the group track to the input of an audio track.
Arm the audio track and (if you want to “bounce” directly without recording any midi data) arm the midi track and keep the focus on the miditrack, and press record and play.
The fact that the freeze files are a bit hidden is something different.
There is a difference with what i think is what you call bouncing (and is in fact only rendering vst to audio to reduce cpu load) directly in the main project window and freezing.
The goal is at some point the same, but the workflow is different.
I think the above given suggestions are correct.
A good thing before you go to a mastering point or any other exchange level between systems is to render the entire project (export) to the audio format.
The freeze function, fwiw and what i think, is there to temporarily create cpu unload within the project, not to finalize a project. Exchanging the project with all the dll info still active creates a lot of compability problems.
+1 Freezing is resource conversion, transforming CPU use to disk use. It is used because the system on which you use it cannot handle much more loading. Freezing still leaves all the idiosyncratic settings on the system intact in the project file, for later re-use, which is not good for transfer, as no two systems have exactly the same settings, plugins or whatever.
Rendering to audio converts flexibility into transferability, as all the internal differences are eliminated.
i agree on the opinion with the manual.