MOTUnation.com

I'm coming up against the limitations of my computer's power in a most painful way and thus forced to explore this freeze selected track feature and its not really making sense to me. The last time I used such a feature was on Cubase SX3, back in the day, before I switched to DP... so maybe I'm just all wrong headed about it.

So I'm wondering if you could

#1 Help Set Me Figure out how I should be doing this
#2 Am I think about it wrong, whats the virtue of how DP is doing this?
#3 Why doesn't it work the way I want it to work.. whats the virtues of the way it works, and whats so wrong about how I want it to work?

So I go and freeze 3 virtual instrument tracks, along with there respective MIDI tracks... seems simple enough.

I consult the manuel and suggests that after doing this you need to set the output of these to none, that DP would do this it's self if not for the problem of multitamberal instruments.

This seems wrong to me.. mainly cause I'll have one channel bussing into this aux channel over there and to this thing over here... and if I go in and set the channels to none.. #1 Its a pain to set to none and then back again if you are going to have to do a lot of this sorta thing and #2 If you have a lot of this bussing into that... It could becomes a problem to actually remember what should be bussed into what.

Not only that, but its not clear to me that all plug ins on the frozen track are really not using up computer resources at this point. I suppose this would be a particular problem if you were trying to manage ram limitations with track freezing?

Is this not a pain point for people who have to do a lot of track freezing?

But that's not the worst of it... The virtual instrument tracks in question have a whole lot of aux send automation going on in them.. and when you freeze the tracks.. the result is an audio track without the same aux sends, and without there aux send automation.

So.. #1 Isn't this kinda... bad design? Or am I missing something?

It seems like this whole feature... is just not thought through well at all.

I suspect that there's a lot of folks who are a lot smarter about DP then I in these parts, and I'm wondering how you might handle this sorta problem.

thanks

mattsearles wrote:I'm coming up against the limitations of my computer's power in a most painful way and thus forced to explore this freeze selected track feature and its not really making sense to me. The last time I used such a feature was on Cubase SX3, back in the day, before I switched to DP... so maybe I'm just all wrong headed about it.

So I'm wondering if you could

#1 Help Set Me Figure out how I should be doing this
#2 Am I think about it wrong, whats the virtue of how DP is doing this?
#3 Why doesn't it work the way I want it to work.. whats the virtues of the way it works, and whats so wrong about how I want it to work?

So I go and freeze 3 virtual instrument tracks, along with there respective MIDI tracks... seems simple enough.

I consult the manuel and suggests that after doing this you need to set the output of these to none, that DP would do this it's self if not for the problem of multitamberal instruments.

I simply mute the tracks (click off the blue play triangle), rather than changing output assignment. The reason you have to do this is otherwise you would have both your MIDI/VI track and the audio track playing back at the same time, doubling the track.

I wish that the VI/MIDI track would mute itself automatically after freezing, since it would save an extra step (or several steps, if you are freezing lots of tracks).

mattsearles wrote: This seems wrong to me.. mainly cause I'll have one channel bussing into this aux channel over there and to this thing over here... and if I go in and set the channels to none.. #1 Its a pain to set to none and then back again if you are going to have to do a lot of this sorta thing and #2 If you have a lot of this bussing into that... It could becomes a problem to actually remember what should be bussed into what.

Sorry, don't understand this part about aux tracks. I don't use aux track on my virtual instrument tracks.

What I do is use track folders. When you create the instrument track, there is an option to place it in a track folder. After freeze, you can click on the folder and it will mute both the instrument and its MIDI track in one click.

What I don't like is that when you freeze and instrument in a track folder, it writes the audio track INSIDE the track folder. I then have to drag the audio track OUT of the track folder before I can mute the folder. Does anyone know of a way to get freeze to write the audio track outside and next to the track folder, but not within it?

I also wish that the audio track would pick up the track color from the instrument track, which would make it easier to tell which audio track came from which instrument track at a glance. But instead it colors the frozen audio track red.

mattsearles wrote: Not only that, but its not clear to me that all plug ins on the frozen track are really not using up computer resources at this point. I suppose this would be a particular problem if you were trying to manage ram limitations with track freezing?

Freeing up resources is one reason to freeze instrument tracks, but I mainly do it as a way to render VI tracks as audio. I like to print everything as audio, either for sending to other DAWs or to make them as generic and future proof as possible, having seen too many formats and platforms come and go over the years. I like to get rid of all instrument and MIDI tracks as soon as possible in a project, so that in the end I'm mixing with only audio tracks. So I freeze tracks as I go along, as soon as I have the performance perfected. With Freeze Selected tracks, you can highlight a bunch of instrument tracks and render them as separate audio tracks in one pass.

Sorry, maybe you could explain more about how and why you are using aux tracks, but I haven't had occasion to use them on instrument tracks.

Best,
Babz

"Freezing selection" is exactly what it sounds like. Assuming your tracks are set up for pre-gen mode, and are not playing in real time, you simply select the area in your Tracks window that you want to freeze, then select "Freeze Selected Tracks" or "Freeze Selection" from your pull-down. This will render an audio track from the selection, whether it's a VI (and its accompanying MIDI track) or an audio track with effects in place. You then simply deactivate the VI or audio track and effects and you can work with the new track created by the freezing process, which has rendered your VI or audio track-and-plugins to a new track. You can even freeze several tracks at once, which will create a stereo submix track. The advantage of this is, if you have all your tracks in pre-gen mode, you are actually freeing up resources, anyway -- the VIs and effects are being rendered anytime your processor isn't running in real time, which frees up resources and also allows you to bounce VIs to disk without rendering them as audio files.

You can just as easily bounce all or a part of a mix to disk in real time and add it to your Tracks window. If you then deactivate all the VIs and plugins involved, it frees up your resources in the same manner as running them in pre-gen mode.

Thanks guys

Hmm... Ok.. so I guess maybe there's a couple of things I don't get and a one glaring problem there seems to be no way around?

I have pre-gen set up as the default.. but I wonder if doing the 32-64 bit bridge would mess with this, or what... cause it seems like I'm not doing THAT much and yet I'm pushing the processor to the max.

However.. my understanding of the pre-gen is that if you're automating parameters of a plugin.. err does it not pre-gen? Or there's something that impacts performance, right?

Point is that that freezing a track would result in freeing resources...

If you simple MUTE at track.. does that free it of its resources or do you have to set the output as none?

What I don't get.. the glaring problem.. is on a VIs track.. I'll be doing aux sends... say into a reverb... and i'll have automation on that... and when I freeze the VI track the resulting tracks don't got the aux sends on them OR the automation for them... and if they don't have that... and I want to work with track freezing as resource management strategy, I'm going to have to really change my workflow.. and that workflow change is going to negatively impact my productivity.

As a rule of thumb I think I'd prefer not to freeze anything till the last possible moment. In part because.. that instrument that's doing whatever on measure 1 through 10... might be doing something on measure 100... and so if I'm freezing in order to have higher instant counts.. or something like that...

How do I explain this?

So technology acts as an intermediary between our selves and the work we are creating.. as soon as I freeze a track... there's like a suggestion that I should not then.. instantly unfreeze it to change something or add something to it.. another words.. freezing is changing the creative choices I'm making.. the software / tools I'm using are... and that has kinda negative aesthetic implications.

So as I'm working... I have to look at what's coming in and out... and figure out when to freeze and when not to... based on that.. and what my resource situation looks like.

Ummm

as far as bussing is concerned... I might make a drum kit that is made up of a number of VIs and then there'll be a drum master buss... and on that buss will likely be a compressor, maybe tab saturation... but something going on to kinda glue the kit together to make it sorta more coherent as one instrument.

There are times when... I'll have lots of... sub master busses.. and then sometimes.. Instead of "I'm going to do the whole master buss compression thing" I'll have a "faux master buss master buss" where... everything but that which I don't want to be glued together... things that I might want to have a greater dynamic range... will go to the faux master buss.

Err, I don't know if I'm achieving the level of coherence that I'd like here? Do I make sense?

First let's look at why are you maxing out your CPU?

What are your system specs?

WHICH plug-ins and VI are you using? (Some, like Omnisphere for example, can be much more resource-demanding than others. )

How MANY track are involved?

And, most important of all, what is your audio buffer setting? Raising that might be a better solution than freezing tracks, depending on the situation.

Babz

You know this is going to be a long list, right?

Let me take a look..

So Early 2008 Mac Pro 2 x 2.8 GHz quad core
8 GB of ram...
snow leopard

The buffer was set to 2048... anything higher is grayed out.. I'm using an Ensemble. Haven't touched the multiplier.

I've got 5 FM8 instances
One Absynth Instance
1 Kontakt Instance
2 Omnisphere Instances (though both loaded with only one sound)

Thats it for instrument instances

So.. for inserts on instruments

3 instances of Nomad Factory Magnetic + 3 more instances of it on aux channels
2 P&M Analogers on VI inserts
2 instances of VirSyn's VTape saturator on VIs and 2 other instances
3 Instances of PSP's RetroQ on VIs and two on auxes
There one instance if Izotope's Vinyl on a vi
There's 2 of Wave's Ren EQ on VIs, and 1 on an aux
One Instance of Guitar Rig on a VI, with Track 12's Lofi and distortion
And there GR with Tracktor's 12's reverb, a custom EQ, equalizer shelving, Reflector (convolution reverb), Tube Compressor and a split mix (most of the modeling going on in here is kinda old)
There' one of Waves's Maxx bass on a VI and one an an aux
1 MW EQ (you know, motu's) on a VI, and 3 else where
There's a VC76... modeled by softtube and native instruments I guess.. on a vi and an aux buss
I have Molot, a freeware compressor, pulling side chain duties on a VI

That's it for the VI inserts

There's 3 altiverb 6 instances..
We got Reaktor with there Space Master Reverb
1 Nomad Factory's Echoes (tape delay)
2 of Waves's H-Delay
3 of PSP's McQ

Oh.. one Waves S1 Imager on a VI and one else where

And we do have.. from MOTU... a Wah Pedal, Springamabob, and soloist.. on a VI

And that's it right now.

I'm experimenting with plugins more then I usually do.. and so that's clearly why it feels like I'm not really doing that much and yet I'm in the red.

Because of the limited resources of my machine, I usually freeze all my VIs' audio outputs, save as an alternate project with their audio tracks, but with the VIs completely removed altogether, and then mix the audio in real time. The VIs, obviously, are what's eating up CPU. I was able to run a high number of audio tracks and plugs in real time at 88.2 kHz/32-bit on my even older 32-bit-only Core Duo machine.

(Serious edit form my previous post: you don't freeze audio by making your tracks pre-gen. In pre-gen mode, you can actually bounce your VI's output to disc without freezing them first. Freezing is for VIs or audio tracks running in real-time. And yes, when you freeze an audio or VI/MIDI track, you are also rendering all the automation for that track)

I'm hoping someone else will jump in, because you are asking some good questions, and some are things that I've wondered about myself, but just haven't the need to deeply research these issues. Also, perhaps some of what you are asking are not strictly technical questions, but have to do with work philosophy, habits, or preferred working methods. But I'll try to contribute some comments where I can.

mattsearles wrote: I have pre-gen set up as the default.. but I wonder if doing the 32-64 bit bridge would mess with this, or what... cause it seems like I'm not doing THAT much and yet I'm pushing the processor to the max.

I don't know. I gave up using 32-bit plugins and JBridgeM and now operate all 64-bit. I only tried JBridgeM on a few plugins and it was flakey or not functional on 2 out of 3 of them.

mattsearles wrote:However.. my understanding of the pre-gen is that if you're automating parameters of a plugin.. err does it not pre-gen? Or there's something that impacts performance, right?

I don't claim to have a deep understanding of what happens behind the scenes with pregen, but to review the basics...

For pregen to work you have to keep plugin windows closed. The rendering doesn't take place until you close the plugin window. (I believe the automation should work behind the scenes as long as the plugin window is closed, but don't know for sure.) Also, some plugins like UAD, etc. have to run in real time, so you need to go to the mini menu and choose "Run this instance in real-time' or "Default to real-time". Finally, with pregen they say it is better to use separate instances of a VI, rather than using it multitimbrally, so pregen can go to work on the closed tracks in the background while you are laying down a new instance live.

mattsearles wrote:If you simple MUTE at track.. does that free it of its resources or do you have to set the output as none?

I would like to know the answer to this too. With my new system so far I haven't found I'm running out of CPU, so I mute freezed tracks, assuming it is freeing up CPU, but maybe you do have to actually set output to none in order to gain back resources.

mattsearles wrote:What I don't get.. the glaring problem.. is on a VIs track.. I'll be doing aux sends... say into a reverb... and i'll have automation on that... and when I freeze the VI track the resulting tracks don't got the aux sends on them OR the automation for them...

I don't usually work this way myself. I use the effects built into the VI, and if I need to process them further, I render them as audio first.

But I trust you know that you have Bounce To Disk as an option, instead of Freeze. Select the Instrument Track, and the Aux Track, and you may need to select the Master Fader too, and then choose bounce to disk and it should print the effects too. Bounce To Disk also has the advantage of being faster than real time.

mattsearles wrote: As a rule of thumb I think I'd prefer not to freeze anything till the last possible moment. In part because.. that instrument that's doing whatever on measure 1 through 10... might be doing something on measure 100... and so if I'm freezing in order to have higher instant counts.. or something like that...

How do I explain this?

So technology acts as an intermediary between our selves and the work we are creating.. as soon as I freeze a track... there's like a suggestion that I should not then.. instantly unfreeze it to change something or add something to it.. another words.. freezing is changing the creative choices I'm making.. the software / tools I'm using are... and that has kinda negative aesthetic implications.

Which is why "freeze" is a good name for the process, isn't it? It locks it down. I can understand why you don't want to freeze or render as audio until the last possible moment. I guess for me it's just a matter of past history and expectations. I came out of tape and hardware, so for me all of this stuff is just bonus, miracle stuff. But if you grew up in the era VIs and sequencers, then you expect to be able to just keep throwing stuff into the project infinitely with infinite options. From my perspective, based on my history and way of working, I actually see too many options and too many choices an impediment sometimes. I try conceive of the project in my head and use the tools to realize that, rather than keep trying things with the tools in hopes of discovering how it's going to end up. (I said TRY, mind you. I'm enticed by infinite choices as much as anyone.) At least I try to commit to things like tempo and key early on. Even if you commit everything to audio, there are still a lot of options, infinite tracks and takes, splices, punch ins, crossfades ... Maybe not as flexible as MIDI, but not exactly severely limited either.

I come from a background of working on less powerful computers, and even worked with multiple computers, hosting all VIs externally until quite recently, so I'm maybe not the best person to be responding here.

I'm now working on a single 2012 Quad Mac Mini and don't use the PCs or hardware anymore, and I'm sure I'll soon run into its limits, but so far I haven't even put a dent in this thing, and I just finished a project with close to 100 tracks.

Maybe the new trash can Mac Pros will finally give us infinite freedom, but what we do can demand a lot and up until now it can still require certain strategies to manage resources.

Babz

mattsearles wrote:You know this is going to be a long list, right?

Let me take a look..

So Early 2008 Mac Pro 2 x 2.8 GHz quad core
8 GB of ram...<snip>

And I assume you are using DP 8.0.5? You don't say.

Off hand I'd say Omnisphere and convolution reverbs stand out as big CPU hogs. Also, 8 GB of RAM seems a little slim.

I don't have a lot of experience with a lot of the other plugins that you mention, but I don't use things like tape saturation -- and a lot of the stuff on your list -- on anything but audio tracks. I try to work with a traditional recording studio metaphor. These are instruments, I get them down on "tape" and then deal with processing. But that's just me. Your way seems perfectly valid for these virtual times, I suppose. I'm just not the best person to comment at this point.

Babz

Babz wrote:

mattsearles wrote:However.. my understanding of the pre-gen is that if you're automating parameters of a plugin.. err does it not pre-gen? Or there's something that impacts performance, right?

I don't claim to have a deep understanding of what happens behind the scenes with pregen, but to review the basics...

Good question. The reason you have to keep the plugin window closed is DP doesn't want to pre-gen and then have you change the plugin settings because it will have "pre-gen'd" incorrectly. So maybe it doesn't pre-gen with automation in write mode because it doesn't know what you're going to write?

mattsearles wrote:If you simple MUTE at track.. does that free it of its resources or do you have to set the output as none?

Babz wrote:I would like to know the answer to this too. With my new system so far I haven't found I'm running out of CPU, so I mute freezed tracks, assuming it is freeing up CPU, but maybe you do have to actually set output to none in order to gain back resources.

No, mute doesn't release the resources. You have to disable the track. Mute keeps the resources so you can mute and unmute and hear the result instantly. If it released the resources, you would have a glitch when you unmute while DP reallocates the resources.

bayswater wrote:No, mute doesn't release the resources. You have to disable the track. Mute keeps the resources so you can mute and unmute and hear the result instantly. If it released the resources, you would have a glitch when you unmute while DP reallocates the resources.

Yes, disable. Turn off a track's Enable (ENA) button to free up resources.

If you don't see the ENA column, you'll need to go into the Tracks Lists Column Setup preference and turn it on.

I might recommend tracking everything before you start adding all the processor heavy plugins. I would print my MIDI tracks to audio - remove all the VI's and then add the processors when your ready to mix - I would use the tape saturation (p&m) Analoger as the first insert on buss channels only and Magnetics as the first insert on the master bus.

My thoughts - I use a Mac Mini i5 2.5GHz 16G ram. My sessions usually aren't huge (less than 30 tracks) so I have few issues. I believe with a few work flow adjustments you just might improve yours.

Best of luck

Dan Worley wrote:

bayswater wrote:No, mute doesn't release the resources. You have to disable the track. Mute keeps the resources so you can mute and unmute and hear the result instantly. If it released the resources, you would have a glitch when you unmute while DP reallocates the resources.

Yes, disable. Turn off a track's Enable (ENA) button to free up resources.

If you don't see the ENA column, you'll need to go into the Tracks Lists Column Setup preference and turn it on.

Not to confuse anyone, but to de-confuse myself, didn't MOTU announce in one of the incremental updates a few years back (or less) that Mute finally releases resources?

Seems unlikely, doesn't it? Mute is supposed to be seamless. Freeing up resources with Mute would cause there to be a gap in the audio when you click mute or unmute, while it deals with the necessary data streams that need shutting down or starting up.

Ok, I guess they probably didn't. Does anyone remember something like that from an incremental release in the past few years? It's probably just me. Never mind, unless someone does remember something.

Shooshie

The manual, page 133, makes it pretty clear. To recover resources, use enable/disable. Mute and unmute keeps the resources allocated to the track to ensure a smooth transition.

"The audio track Enable/Disable option ... allows you to temporarily take an audio track off line to free up its computing resources."

"... to simply mute and unmute a track ), leave it enabled and use its play button to mute and unmute it. Doing so preserves the track’s system resources and ensures a completely smooth transition."

Remember that with DP8 you can now drag and copy sends as objects, so setting up routings like this is quite a breeze!


Frankly, this whole Freezing business workflow has never ever worked for me. And I've tried it.

There are other approaches which, IMO, are much more effective to deal with some of the things you want.

You want a quick way to print tracks to use the audio and archive the VIs to reclaim CPU resources, correct?
You want a quick way to deal with this workflow and not waste time muting, enabling, and rerouting things, yes?

If so, you will need a template, my friend. A very good and thought-out one.

Read this thread and see if you like that workflow better than freezing. All I can tell you is that it changed my music-producing game, and allowed me to survive with a mere G5 (with slaves) for years, while being able to do quite complex projects.

http://www.motunation.com/forum/viewtop ... 26&t=50004