Freezing

[Jaeson Merrill]

gol

no offense, but your post is full of assumptions and generalizations..

Flstudio totally rocks, and its indeed, imo the best software for what it does.

however, freezing CAN be useful for ANYONE at ANY point in the songwriting/producing process.

you can as well play your track realtime, and you don't need freezing

not true. When you are totally done with a part, it would be best to just "freeze" it, keep it tucked away, make it so it has no hit on the cpu, and move on. Then if you need to alter it, unfreeze and alter. by then you prolly would have frozen other tracks, so the cpu usage always stays at a low.

sounds like a burden but this workflow logic is quite easy to use.

[Karen-K]

I agree with Jaeson
For me realtime modifications, active/freeze and Bypass/unfreeze functions in freeze mode are the key- stone of the plugin.
If you can't modify the content of your MIDI part for example,after frezzing it, no matter if you call it "freeze" or "bounce" or even "mixdown" it's the same thing and it doesn't help.
The freeze basic function is to save CPU ANDto let you edit your work later if you need.
So Gol I have to say I don't really understand your opinion on this one.
Maybe you can explain in other way
Thanks in advance
Karen

[jmh]

Freezing - yet another hot topic that'll most likely make people at ImageLine and the loyal followers see red

Thank god the functionality is there already, making a macro for it will undoubtedly help... but an implementation a la "the big boys", now that would be something indeed...

Regards,

JMH

[Improv]

and no, it doesnt take long at all, that is a myth. perhaps cubase sx,

In SX 2 you need to set a default length for your freeze files. Users on cubase.net started posting that SX freeze was too slow. Turns out though that their default was set to 10 minutes length, so even 30 second long parts were taking as long to freeze as 10 minute tracks!

SX freeze may be slower than others, I don't know. Hopefully the SX3 upgrade has improved freeze.

Cubase SX has also 'frozen' or written to a wav file since SX1. They call in 'Export to Audio Mixdown'

[Jaeson Merrill]

Freezing - yet another hot topic that'll most likely make people at ImageLine and the loyal followers see red

/me raises hand

loyal follower here!



and the functionality is SORT of (well mostly) there.

still, a nice way to totally disable vst effects and instruments is needed.

[tony tony chopper]

by then you prolly would have frozen other tracks

and if you freeze too many of them you either get poor performances (if streaming the resulting audio tracks from disk) or huge RAM usage (if keeping them in RAM)

in my work, i use freeze more of a preventitive measure than a "shoot im out of cpu" thing

if you freeze things while you're not even over a 50% CPU usage, it's a little stupid. Freezing is not fun, it prevents you to play with your scores realtime, it's only a workaround when you don't have enough CPU.

If you can't modify the content of your MIDI part for example,after frezzing it, no matter if you call it "freeze" or "bounce" or even "mixdown" it's the same thing and it doesn't help.

so you imagine you can freeze a track and still be able to edit the score without unfreezing/refreezing? Oh yes I see, some freezing plugins sample a couple of keys, then play those back. Well, give a try to them and you'll see.. if it's what you're looking for, FL will definitely never have this, since it sucks.


And I AGREE that in some apps, generators are independant enough to be able to render them separately, so if you have a generator that eats 10% CPU in a mix that eats 50% CPU, it will only take 6 sec to freeze a 1 min part.
BUT in FL generators and effects can interact (peak controllers and other internal controllers), or simply have some randomness. This is why you have to render the whole mix to freeze the generator, thus requiring 30sec for the same 1 min part.


I just makes things clear, because freezing was this year's hyped world, and a lot of people don't understand it but still want it, thinking it's a 1-click magic CPU saver, without ANY downside. Yes, there are downsides, freezing is not fun to use, it's just a workaround. It's certainly not instantaneous, and it's certainly resource-hungry, they're just other resources than the CPU.

[/quote]

[Sascha Franck]

Of course, if your song doesn't eat much CPU, like 10%, it's only gonna take 20sec to freeze. But if your track only eats 10% of your CPU, then you don't need freezing.

This is plain nonsense, actually all your post was.
You freeze whenever you need to free up *some* resources - instead of freeing up ALL resources, which is what you're talking about the whole damn time.
So, in case you're at, say, 80% CPU consumption but want to add something that'd use up like around 25%, you'd just freeze something taking up 10% and had enough power back.
So, in that case bouncing all the stuff would take up WAY more time than freezing (if implemented properly).
Also, in case it's implemented properly, you wouldn't have to care about deactivating anything to really free up resources.

Check out freezing in LogicPro once and you'll just know what it's all about - it's nothing short but marvelleous.

[tony tony chopper]

you'd just freeze something taking up 10% and had enough power back

freezing when you're only at 10% CPU usage, now that's what I call nonsense.. but you do it the way you like.

[Glooper]

you'd just freeze something taking up 10% and had enough power back

freezing when you're only at 10% CPU usage, now that's what I call nonsense.. but you do it the way you like.

Thats not what SF is saying...

He's saying (and correct me if I'm wrong ) to play back an entire song (i.e. all the tracks at once) takes up 85% CPU. This CPU usage can be broken down to each track; so the bass synth could take 10% CPU, the lead line 25% and a couple of pads 40%. Now the person writing the song wants to add a new synth line but knows that the synth takes up 20% CPU usage, so needs to get extra CPU power from somewhere as 85% + 20% = 105%, which would mean the song could not play in realtime. So in freezing say the Bass Synth line (which takes 10% CPU) will bring the total CPU usage down when playing the entire song, (85% - 10% = 75%). Which then leaves enough room to add that extra synth (75% + 20% = 95% ).

See... this is why you would freeze tracks that only take up say 10% CPU usage.

Ben...

[tony tony chopper]

See... this is why you would freeze tracks that only take up say 10% CPU usage.

But I'm saying you can't do this in FL, because generators or effects can interact, so let's say your track that's eating 10% CPU usage is manipulated by an internal controller in another mixer track, or another generator, you have to play everything. Thus it won't take 10% of the song time to render/freeze, but 85%.

This will get even more complex in FL5, which will introduce automation clips, that can be automated as well (yes automation that can be automated).

[Kriminal]

See... this is why you would freeze tracks that only take up say 10% CPU usage.

But I'm saying you can't do this in FL

You can in other hosts.

[tony tony chopper]

You can in other hosts

yes and they don't have internal controllers

Reason has CV modules but can't freeze neither.

But ok I could make a freeze just for you that doesn't guarantee the frozen version to be the same as in the song itself.
In fact, no host can do this, since plugins can have some amount of randomness. But this is less important/noticable than interaction between modules.

[Jaeson Merrill]

See... this is why you would freeze tracks that only take up say 10% CPU usage.

But I'm saying you can't do this in FL

You can in other hosts.

geez, talk about taking something out of the context..

[Jaeson Merrill]

gol, i understand your reasoning a bit better now, and i thank you for your patient replies.

freezing is not the saviour of the world. But it CAN make things alot easier.

and if you freeze too many of them you either get poor performances (if streaming the resulting audio tracks from disk) or huge RAM usage (if keeping them in RAM)

well yeah if you do TONS of tracks this way. You would probably need only 5 or 6 max, maybe more, but not likely. and there could be an option to freeze at 16-bit even.. and other options perhaps..

But I'm saying you can't do this in FL, because generators or effects can interact

and this is very true, theres a lot of potential for interoperation in FL.. which freezing would certainly kill if applied wrong. However, we can freeze the tracks that DONT use internal controllers, and leave the others

or perhaps thered be a way to just freeze the whole lot, internal controllers, the generators linked to them, the effects applied to them, and then disable them completely, with one click of a button to bring them back. now theres a challenge.


you know what gol, the one thing that really erks me is the lack of a way (in any host) to just ARCHIVE something (thats a cakewalk word, so maybe sonar does it). .. but the ability to archive a channel, to UNLOAD it but save its *fst in a little placeholder where the track once was... then you could click that, it would reload the plugin with the former preset there, and bang, back to normal.

that functionalty would need to be there with the freeze; which again, should just be a macro, but it would also be cool if this "macro" had some options in it....

gol, i totally cant wait till FL5.. I still dont know how to use half the stuff in FL4, and i use it alot, read the helpfile all the time, and search for more knowledge on the program. Its complex when you want it to be, simple when you need it to be.. intuitive and fun also.

youve made an out of control software beast!!!

thank you.

im not just some mindless freak following buzzwords; please dont categorize me as such. I first saw an example of freeze a long time ago in cool edit pro's multitrack interface, it would save cpu by "locking effects" ... which im not totally sure exactly what that was, but it rocked i always saw the whole, render and disable thing as a way to help my projects along that were suffering from hi - cpu use.. i started on a bloody 200mhz for crying out loud..

now im on 1.7ghz, im way behind once again.. lol

[kritikon]

I really don't understand why anyone gets overheated about freeze. I'm still waiting for my new PC to arrive so I can get to grips with SX2 - but I probably won't even touch the freeze function. I've used VST5.1 for ages, and it was never a problem freeing up resources.

All you do is render to audio (which is exactly what freezing is). Then you keep the original midi track and sequences etc, but simply switch off the VSTi and any FX that it used and mute the track. They are still there, still recallable, but taking up minimal resources. If you later want to change the audio recording - you reactivate the VSTi and FX and midi channel and edit it, then render to audio again - exactly what freezing is doing, except you have to click your mouse a couple more times - how difficult is it to click your mouse?
It's not a workaround, it's just another way of doing the same thing. And there are very few VSTis or FX that take up any noticeable CPU resources if they're switched off but still loaded.

All freeze is, is one click to deactivate channels and render to audio - it isn't any kind of magic that doesn't record to .wav.

Surely with FL you can deactivate VSTi, but keep them loaded? - I'm pretty sure you can in most of the other hosts.

You're not losing absolutely anything by not having a freeze function, apart from maybe 10 seconds that it takes to deactivate a VSti and a couple of FX - and the increased speed of a single channel render possibly make up for that anyway.

I infer from this that when some people render to audio, that they delete the midi sequence and the channel? That's user error not lack of functionality that's the problem.