Big Feature request: Autofreeze mode

[~ufo~]

I'd like to see some sort of auto freeze mode, that lets you put certain or all active plugins in a state where they are in a hybrid state between live and frozen. When you're tweaking them they are live and after an idle time (e.g. 5s) after the last parameter change, they automatically start using idle CPU cycles to progressively freeze. Preferably this would occur not from start to finish, but from the playhead position outwards, but going backwards in time will likely not work. So I guess from slightly before the playback head onward and when that's done it can start from the top to complete the rendered file.
Depending on the load and capability of the processor, this could be in real time (even saving live streams during playback), to sub or super realtime rates.

The advantage of such a system would be that it would free up CPU resources and divide processing much more evenly over time, avoiding spikes as much as possible and allowing for a more stable feeling system, since there's few(er) live processes going on at any given time.
It will create more CPU headroom, for instance allowing you to use a heavy reverb during tracking on playback tracks, because it'll automatically get rendered once you're done tweaking it and the input doesn't change, or even on live input tracks since most of the other processors have been rendered already or are being rendered.
Of course it will also eliminate the time consuming unfreezing-tweaking-refreezing cycles some of us have to go through quite a lot.

Someone once told me that if you do something (digitally) more than twice, it's worth automating.
Well, a boatload of our processing is happening identically way more than twice in our sessions, which needlessly taxes our capable processors. Especially during low buffer recording/production sessions this can cause issues with some plugins.

An autofreeze function like this, in my opinion would be a very welcome evolution to native DAWs and would further fade the difference between DSP and Native into the past.

Thanks for your consideration.

[midnightrambler]

Where's the "vote down" button? All I can see from that idea is super-hassle. E.g. tweaking a send level to a reverb on a bus you haven't touched for 5 hours and suddenly finding the playback stopping while waiting for the track to unfreeze, wait for plugin to instantiate, etc etc.

[BScout]

Originally Posted by midnightrambler

Where's the "vote down" button? All I can see from that idea is super-hassle. E.g. tweaking a send level to a reverb on a bus you haven't touched for 5 hours and suddenly finding the playback stopping while waiting for the track to unfreeze, wait for plugin to instantiate, etc etc.

Exactly

[~ufo~]

Originally Posted by midnightrambler

Where's the "vote down" button? All I can see from that idea is super-hassle. E.g. tweaking a send level to a reverb on a bus you haven't touched for 5 hours and suddenly finding the playback stopping while waiting for the track to unfreeze, wait for plugin to instantiate, etc etc.

Of course, an implementation like that would be no good.
If this can't be implemented without solving more hassle than it creates, then it obviously shouldn't be implemented.

The idea is that it should be a seamless experience that is BETTER than the current freeze functionality is.
This plug-in instantiating you speak of should not exist. I'm not even sure it really exists in the normal freeze/unfreeze functionality. You can't open the plugin when it's frozen, but does it really re-instantiate when you unfreeze it? I'm not sure.
Regardless, since there is such a thing as dynamic plugin processing already, this should not be necessary.
As soon as you grab a control, the plugin will receive live audio again and will affect the sound. As soon as you change a send, the same would occur.
There should be no playback stop or noticeable hiccup in this functionality.

The idea is that you don't notice that the plugins start freezing when you leave them alone and don't notice that they go live again when you tweak something or they receive a different input. Just like you don't notice dynamic plugin processing at work, you shouldn't notice this.

[midnightrambler]

Yes if as a user you don't notice then that would probably work quite well.

On a slightly different note, it would be interesting to have a poll to see how many people use "freeze" on a daily basis. I can't say I use it a huge amount, and when I do it's usually for a reason other than to free up resources, but that might just be me.

[amagras]

The idea is not bad if it can be implemented completely invisible. However I would be even happier if it was possible to rent RAM memory from the Avid Marketplace when working on demanding sessions

I use Track Freeze a lot, to save resources, to be able to record without ADC latency, to force myself to realize that guitar take is the one...

[~ufo~]

I use it a lot.

For super heavy plug-ins like Abbey Road plates.

But since I do stem mastering within the mix session, putting 8-20 parallel clariphonics, multibands and plo-l2s after the mix, well I don’t usually have DSP room to spare by that time. So I freeze the buses a lot and only unfreeze them if during the mastering process, I feel like the mix should be tweaked.
If I were running stereo mixes only and doing mastering in a different session, I’d probably use freeze less. But I do usually prefer to freeze any VIs during mixdown in stead of committing.

[TrackerLe]

Sry but this feature will never come...and is a little bit stupid, if you understand the mechanism of an audio engine...


To do something like that, you need an audio engine, which can do both at the same time. Realtime Playback and Offline Bouncing...to freeze a track is nothing more, than bouncing a single track (offline).Auto freeze isn t possible, cause to freeze a track is always a offline operation, where the audio engine is bouncing a single track.
So its not possible to do that in the background next to normal operation like playback or recording. Its easy to understand, if you know what offline rendering of audio tracks means... Sry, but this idea is not possible... It would be cool, if the audio engine could look into the future and see, what to bounce offline

[~ufo~]

So.... would it be impossible to run Pro Tools in real time while reaper is doing an offline bounce at the same time on the same computer?
Probably not.

Just because this programme can't do this currently, doesn't mean it's not possible.
I'm not a programmer, so I don't know, but I'm not going be so quick to dismiss it as not possible.

Regardless, it need not actually work as offline bounce if that is somehow not possible.

It can work in real time by just saving the audio streams of the insert banks outputs that haven't been tweaked, automatically switching those plugins to idle (like dynamic processing does when they don't receive audio) and playing back those recorded streams in stead.
Every consecutive playback of a part of the timeline that was already saved, will run on considerably less resources.

If offline rendering during playback is not possible, as you suggest, than it can always take place during stopped playback, as a background task.
However, I don't see any reason why, say 20% of the CPU could not be allocated to render some files. Does every audio suite render take up the whole audio engine too?
If background rendering is not yet possible during playback, then this is something that should be developed I think. But, the lack of it need not stop the development of the functionality I propose. It can run in realtime during playback and/or using idle time during stopped playback.

[midnightrambler]

Another potential pitfall : I've got a delay on my track which has some automated feedback on which is responding dynamically to the vocal. I can't really see how that can be done as a background task, because the track can't be accurately frozen unless the vocal is actually run through it as a complete pass. Can't really see a way round this in order for it to be done "invisibly" to the user.