Freezing

[meister eder]

Freeze just isn't that amazing I'm afraid - any of you with a decent host can already do everything any freeze function can do. I'll bow out ungracefully now.... To me, functions like the Warp thingummy are far more useful and interesting than anything Steinberg or anybody else does with Freezing - they can make it as fast, slow as they want - it's just a bone-idle bugger's short-cut is all.

[kritikon]

[meister eder]

[Lunch Money]

I can't believe how... thick... people are sometimes. I don't usually use such harsh terminology... but consider this:

- people are arguing about semantics, it seems. Whenever we say "unload" or "mute" or "disable", what we're talking about is the plug-in NOT using CPU cycles and NOT staying in memory. For all intents and purposes, the host creates a "placeholder" and remembers what your plug-in was set to for when you un-freeze. Then ALL that's left on said track is a rendered audio file, which is much easier on CPU and streams from disk (hence, no impact on RAM).

- Cubase SX2 freeze is crippled and useless, so don't go by that. A properly-utilized freeze function (ie. the one in Tracktion) brought me from an impossible edit (ie. the CPU meter was always going into the red, making my audio stutter and cough until it disabled itself) to only about 5% CPU usage. How in the hell is THAT useless? Jeeziz...

Obviously there are still people missing the point. If you have a shit-hot computer and can run 50 tracks of audio loaded with plug-ins (even the fastest 'normal' computers [ie. p4 3.x or AMD64 3xxx) won't handle 50 full tracks loaded with plug-ins) without choking, then you'll never use it.

For the rest of us, (in my case, on my Athlon 1700+, though I just popped in a 2500+ that I'm trying to get working) rendering is absolutely vital to completing a song, and freeze happens to be the most elegant rendering solution, especially if you don't want to "commit" to the render and want to be able to change settings on your tracks.

It's not a buzzword, it's not useless (if your host does it properly), and it IS something that most users want in their host. Obviously you can do similar things with render, but only if your host does not process plug-ins on muted tracks. If your host does NOT disable plug-ins in muted tracks, then you're pooched.

Greg

[BitFlipper]

- people are arguing about semantics, it seems. Whenever we say "unload" or "mute" or "disable", what we're talking about is the plug-in NOT using CPU cycles and NOT staying in memory.

Actually, as I mentioned in a previous post, on Sonar at least mute-ing a track does NOT free up the memory or CPU cycles. The track is still playing back into all it's effects, but the output of the effects are what is muted. This is so that the track is ready to be unmuted at any moment. Delays, reverbs etc will be already fed correctly and the track will sound right when unmuted during playback. The only way to reclaim memory and CPU cycles from a specific track in Sonar is to archive the track (or remove it completely).

I am not sure how other hosts handle mute, and I won't be surprized if they do the same thing (how else would they work around the problem?). It should be easy to check by just muting/unmuting a CPU hogging track during playback and checking CPU usage.

Anyway, since you were saying that it's all the same thing, I just wanted to say that it is not always the same thing.

BitFlipper

[meister eder]

I can't believe how... thick... people are sometimes. I don't usually use such harsh terminology... but consider this:

- people are arguing about semantics, it seems. Whenever we say "unload" or "mute" or "disable", what we're talking about is the plug-in NOT using CPU cycles and NOT staying in memory. For all intents and purposes, the host creates a "placeholder" and remembers what your plug-in was set to for when you un-freeze. Then ALL that's left on said track is a rendered audio file, which is much easier on CPU and streams from disk (hence, no impact on RAM).

My dear Lunchy,

please consider that it is unfortunately not possible to read your mind. How on earth should anyone know what "to unload" means for you. You know, that's what terms were invented for: To make it possible to communicate, while knowing what the other one is talking about. If a term is not clear, misunderstandings can be caused. So in this case: When someone tells me to "unload" a plugin, I will instinctively take it out of the signal chain. When someone tells me to shut it off, I will probably mute it. You see, that's what the terms mean to me.
Now if you are discussing how to do something (which was the case in this thread), it is necessary to be sure everyone knows what is meant.

Of course "we" (whoever that is in opposition to your "we") know that the goal is that the plugins do not use CPU cycles. But so what? What's the point in discussing how to do it, if you don't care. Sounds like a little child that keeps crying "I wan't! I wan't! I wan't!" while you try to explain him/her the complexity and details and thus the difficulties of what he/she wants.

Interresting as well is that your "we" presuppose that it's also about the plugins not staying in memory, as most existing freeze functions do not free up memory. Aaah, there we are about "unloading"...

You might get now, that this is not about semantics but about realisation - a process where things have to be defined - and if they are not, they have to be described. Things sometimes tend to be a bit more complex than we wish them to be.


EDITED to correct typos only.

[meister eder]

I am not sure how other hosts handle mute, and I won't be surprized if they do the same thing (how else would they work around the problem?). It should be easy to check by just muting/unmuting a CPU hogging track during playback and checking CPU usage

In Logic if you mute a track it is the same as you described for Sonar, but if you mute a plugin, it is disabled and/or bypassed - and thus uses no CPU. The latter is how 'freeze' is handled and realized.

[BitFlipper]

I am not sure how other hosts handle mute, and I won't be surprized if they do the same thing (how else would they work around the problem?). It should be easy to check by just muting/unmuting a CPU hogging track during playback and checking CPU usage

In Logic if you mute a track it is the same as you described for Sonar, but if you mute a plugin, it is disabled and/or bypassed - and thus uses no CPU. The latter is how 'freeze' is handled and realized.

Baie dankie, dit maak heeltemal sin vir my...

--- Yes, that makes sense.

BitFlipper

[Sascha Franck]

The way to maximize the freezing effect is what people do since ages by bouncing and reimporting:
- Bounce things down
- Reimport on an audio track
- Bypass (the mute term might be a bit confusing as muting "tracks" indeed is not the same as bypassing plugins - at least in the hosts I know of... but then, Logic indeed frees up some CPU cycles on unused/muted tracks) all plugins
- Unload plugins that would use up RAM, even in bypass mode (softsamplers for instance)

All this should happen in the background and IMO the user shouldn't even notice that the MIDI track is replaced by an audio track -> it should still look like a MIDI track.

Here's how freezing should work in an ideal world (at least for me):

- When you freeze a track (regardless whether it's a virtual instrument or audio track), one would have an option to only freeze parts or everything. This is somewhat important for virtual instruments.
I really don't like losing insert FX, especially in case they're not using up much CPU cycles - think compressors or EQs. These are even essential when it comes to mixing, and therefore having access to those without having to unfreeze the complete track (which might result in CPU overloads) would just be nice. From what I know Logic freezes in everything but sends, levels and panning info. Still the best solution so far, yet not perfect.
As said, an option to only freeze the most demanding things (usually these are some virtual instruments) but keeping everything else intact would be perfect.
Obviously with an option to freeze everything as well.

- One should still be able to cut and move frozen MIDI parts, without having to deal with the imported frozen-audio file. I think Logic doesn't allow this (correct me if I'm wrong). From what it reads like, SX 3 is supposed to allow for such things.
As soon as some action would require altering the source MIDI track (example: quantizing, cutting overlapping notes) the host should ask whether you'd like to ignore it and keep the track frozen (might make sense in case of overlapping notes) or unfreeze it, so you could modify the source MIDI material.

- All frozen-in plugins should be bypassed automatically (well, that's what's happening anyways, at least from what I know) and in addition, there should be an option to completely unload RAM-hungry plugins (even a bypassed sampler won't release the RAM it's using for the samples) while still being able to reload the very same patch as soon as the track is unfrozen!

- As soon as one would try to alter something on the frozen plugin's settings, one should be asked whether the track should be unfrozen.

- It would be perfect if one could freeze group/folder tracks (example: drums playing through multiple tracks and instruments, orchestral stuff, horn sections, whatever) in one go, without having to freeze each track separately.
Should be possible in all hosts offering group/folder tracks - after all it's nothing else but some sort of macro.

[meister eder]

- One should still be able to cut and move frozen MIDI parts, without having to deal with the imported frozen-audio file. I think Logic doesn't allow this (correct me if I'm wrong). From what it reads like, SX 3 is supposed to allow for such things.
As soon as some action would require altering the source MIDI track (example: quantizing, cutting overlapping notes) the host should ask whether you'd like to ignore it and keep the track frozen (might make sense in case of overlapping notes) or unfreeze it, so you could modify the source MIDI material.

This is exactly the next step that I expect from refining and further developing the freeze function.
Or let's expand it to a somewhat wider definition: Everything that could be mirrored and applied to the origin of the freeze files in the background should be possible to apply to the freeze file itself.

For all your other points: Absolutely agreed!

[Sascha Franck]

Or let's expand it to a somewhat wider definition: Everything that could be mirrored and applied to the origin of the freeze files in the background should be possible to apply to the freeze file itself.

Defenitely!
But, just as you, I'm sure (now that the "we got the coolest freeze function" battles have started) we could expect something really comfortable in almost any host pretty much soon.

[Jaeson Merrill]

yes, freezing IS just a macro, but a powerful one..

here is my idea for freezing in FLStudio...

anyway, there would be some small button on each mixer track, like so





the light blue ones are the button, and the dark blue ones are what it would look like if it were selected. (only alot better cause im not good at graphics AT ALL.. hehe you get the idea)

so, you click the mixer tracks you want frozen.

then, there can be a macro called "freeze" in the macros menu.

hopefully also, a shortcut, like alt+ctrl+f or something...

it would bring up a menu similar to the render menu,
except smaller, and with different options such as:

16 bit, 32 bit, and so on.
and also an option for making seperate tracks for different mixer slots, or just combining them all on one track.

this menu could also be bypassed by having a couple of "Freezing" options available in the "project properties" menu, and it would just bypass this menu and make it faster...for multiple freezes.

ok, so then you hit freeze!!!

the mixer slots ask "what generators are linked to me?"

it solos those generators, and then renders the whole project (or even just parts, im not sure how that would work).

where does it render to? Well, as a sub-subject, it would be nice if FL implemented a "project" folder which you could define in the project properties menu. If you dont define it, it would have to prompt you, but otherwise, it would automatically save everything having to do with that project (freeze files, .fst, .flp, .fsc, other files associated with the project) in that one neat folder, which would rock.

ok so anyway, we have the files rendering and going to the "freeze" subfolder of the selected project directory.

after this, the tracks are entered into the playlist, and channels are created for them, as audiotracks. these are routed to the master by default, but any FL channel is anyway, so no biggie there.

it would be nice if there was an option to trim silent parts, so they dont have to stream silent parts of files from disk.

the audiotracks name should reflect the mixer track it originated from, for instance, "audiotrackfx16".

So what happens to the frozen generators is what comes next.

the freeze macro then makes a .fst (FL state file for those who dont know, it contains everything about that generator or effect, and is better than .fxp in this case cause it also work with FL plugins) that references to the former generator i.e frozenboobass(1).fst and places it in the freeze directory under the project directory.

then, it replaces the original channels with an empty "frozen" channel, that again, reflects the former name of the channel "fr.boobass(1)"; thereby unloading the plugin from RAM, essential for plugins that are always processing data, or softsamplers or ROMplers (ahem... BFD!!!! uses up to a gig at a time!!!). There could also be an option in the freezing options to unload from RAM or just disable, which would be nice for those who wouldnt want to.

this way, the piano roll data or automation (i think) can be left alone, for future unfreezing.

after that, all "frozen" channels are grouped and zipped.

what about the fx?

ok..

now, those former fx slot(s) turn ice blue, or something to show its frozen, and all the fx on it are automatically muted, without any clicks at all from the user.

(smart disable should also be enabled at this point)

ok, there you go. everything is disabled, the audiotracks are placed, and you have saved alot of cpu and perhaps you went and took a bathroom break in the meantime. nice job!!!


what if you want to unfreeze???


heres where the UNFREEZE macro comes into play.

1.click the mixer tracks that you wish to unfreeze, then click the unfreeze macro, or hopefully some shortcut alt+ctrl+u.

2. audiotracks are deleted, their channels also. original files discarded.

3.the fx racks taht were frozen now re-enabled any plugins that were muted due to freeze.

4. the frozen channels find their corresponding .fst files, and are ungrouped, and unzipped.


done!


now, how would FL remember how to unfreeze once its frozen?

simple, just make a .freeze file of the changes, for each mixer fx rack slot. i.e. fx10.freeze, fx16.freeze, and so on, so that it knows just what to reverse.

well, i have never done a line of coding, so i have no idea how hard it would be to implement, but im sure it CAN be done.

[Jaeson Merrill]

i also thought about freezing generators only... this could be implemented side by side with freezing mixer slots, the program, when the freeze macro is initiated, could sense whether mixer slots are selected, or generators. there could be an error msg that pops up if you try to do both.

anyhow,

there would be similar buttons next to generators like this: (forgive the horrid artwork)EDIT: or duuuhhhh you could just select the channels the normal way.. sheeesh



click which generators you want to freeze.

hit freeze macro!

options menu pops up unless you have specified your own options already.

in generator freeze mode, you would HAVE to select seperate tracks for a reason i will make clear below.

there can still be options for 16, 32 bit and sampler quality and so on; as well as the "unload generator from RAM" option.

render! in generator freeze mode, it would have to bypass the mixer slots, because they will not be frozen in this instance. so you would get a dry render....if you want to freeze the fx too, just use the mixer slot freeze instead.

then it places the audiotracks on the timeline where they belong, again, trimming silence.

the audtiotrack channel is then routed to the same mixer slot (if any) that the generator was, allowing for the fx to still work.

then, just like the mixer slot freeze, the freeze macro then makes a .fst (FL state file for those who dont know, it contains everything about that generator or effect, and is better than .fxp in this case cause it also work with FL plugins) that references to the former generator i.e frozenboobass(1).fst and places it in the freeze directory under the project directory.

then, it replaces the original channels with an empty "frozen" channel, that again, reflects the former name of the channel "fr.boobass(1)"; thereby unloading the plugin from RAM, essential for plugins that are always processing data, or softsamplers or ROMplers (ahem... BFD!!!! uses up to a gig at a time!!!). There could also be an option in the freezing options to unload from RAM or just disable, which would be nice for those who wouldnt want to.


this way, the piano roll data or automation (i think) can be left alone, for future unfreezing.

after that, all "frozen" channels are grouped and zipped.



unfreeze???

same thing, mark the channels you want to unfreeze... then use the unfreeze macro.

does the same thing as in the mixer slot freeze, except it doesnt have to un-mute the fx, since they were not effected.



this could be VERY helpful.

simply rendering the track DOES NOT do enough.

you may ask, why have quality settings??? if we want to freeze, just do it at linear and 16-bit right??

wrong, this isnt just about freezing, its about archiving too... what if youre totally happy with a synth track and you want it to stay that way??? just freeze it! MAYBE youll unfreeze it later.. but prolly not, which saves big on CPU, even if it takes a while.


respect to gol

[LoRez]

It's just counter-productive.

If you want to do something with it, don't freeze it... just render it and have done.

Greg

Sorry Lunch, but I seriously disagree....how is having more capability counter-productive? I realize novice users could get confused, but I don't agree that it is somehow less prodcutive to actually have some ability to DO something with your frozen track. Maybe one is trying to do more than just save resources...and you can't groove clip a live midi synth until it is audio. freezing in this way allows you to make cool audio loops from your synth parts. I just don't see how taking this ability away would make it MORE productive.

[Lunch Money]

Dr. Wacklery:

I don't expect anyone to read my mind, and I wasn't suggesting that freeze should work the same way in each host. All I was doing was pointing out that at one point in time, one member was taking semantic issue with the word "unload", when the context (at the time) was clearly that the original poster was talking about taking the VST out of using CPU cycles.

I suppose I shouldn't have used the royal "we", but I admit I had a specific group of people in mind who share my opinion that the only real point of using a freeze in the first place *IS* to free up CPU cycles. The only other possible purpose is to produce a less cluttered workspace.

Back to the reading of the mind-- it had nothing to do with mind reading and everything to do with the context of the post. You don't need to be a mind-reader to understand who I was responding to. Or maybe you do. I'll admit that I usually post on here when I'm tired, and perhaps I was not as lucid as I thought I was.

BitFlipper: I can see how Logic's handling of mute could be a very useful way of implementing it so that you can have unstuttered, glitch-free muting and unmuting. My only point was that if your host does NOT unload CPU with mute, then a render and mute will not simulate freeze. I wasn't judging hosts that don't unload.

LoRez: if you want to continue manipulating the audio, you're not really freezing. That's my only point. I agree that being able to continue with the frozen track could be useful, but not in the way that it was described.

[edit: Also, ideally once developers include a bunch of freeze functionality, you could set up your 'preferences' for a default freeze mode and also give a context menu for when you deviate from your preferred freeze method.]

Greg