Freeze-flex real-time background freezing of channel inserts/ groups/ vsti

This is a suggestion …

Could be called seamless rendering - background render - flexi-freeze etc…

A feature available to be selected on each track, probably enabled on all by default that would render the plugin chain automatically into the audio when the track is deselected.
No need for volume or non plugin automation to be rendered.
That stuff uses almost no CPU.

The uneffected original audio would be saved in the background , and could be called up if needed.
The plugins in the chain are back to real-time processing if one of them is opened up using the original audio so that you can hear the changes real time.
When the track is de selected again it is rendered slowly in the background while Cubase continues working. ie no waiting.
The processing could be real time until the rendered track is done to make it seamless. Perhaps switching the rendered version in automically the next time playback is stopped after it’s ready.

The same thing on group tracks would also be awesome.
We all use a lot of group processing to streamline mixing.
No group audio is shown in Cubase like now, but an audio file could be kept in the background until a change is made in any of that groups inputs or that groups channel plugins.

Vsti tracks could do the same.

You could have huge HUGE projects on a modest computer and it wouldn’t be a pain or take time to deal with ( like offline rendering ) and its much more flexible than freezing and no waiting. No need for multiple computer setups.

Anyone agree that this would be great ??

No, it would just take up a shit load of space on the hard drive. It will also mean a re rendering every time you change a knob slightly in a plugin.
You can already use the freeze button, so i don’t see any reason for this.

Also what would happen if for example you have 5 plugins that are now rendered and you change a knob in the first plugin? You would either have to wait for it to render it all again or revert back to the original and putting all plugins to live again. Changing a knob in the first plugin will affect how the rest of the plugins will react.

I don’t mean to render each plugin by itself. I mean the whole chain.
It really wouldn’t take up more space than freezing the tracks maually … why would it?

Read through again. No waiting. Also group freezing.

A quick explanation of what the idea is ;

Why couldn’t the freezing be done in the background therefore no waiting? Limited to say 10% of available CPU . While your still listening / editing / recording the project.
Cubase can use real time processing until the frozen version is ready then switch automatically freeing up the CPU automatically.
If you want to adjust a plugin cubase already froze Cubase switches back to the original audio and real-time CPU on that entire chain … then freezes the track again after your done.

So for example this idea wouldn’t work well on the master bus because the whole project would have to be re frozen every time one plugin on any track is adjusted.

On most groups it should work well.
If you had for example 5 guitar tracks feeding 1 guitar group track and you changed 1 of the guitars.
The guitar track you changed + the guitar group would have to be re frozen.

You don’t get my point i think.

Let’s say it does what you suggest, for example you have an audio track with 5 plugins. Now as this is done in the background, at some point the render is finish and Cubase needs to disable the original track with plugins, load and switch to the rendered file. This switch will give a stop in playback by itself when it happens. Now you wanna change a knob in the first plugin, then Cubase would have to load original file again and enable all plugins which will give a break in the playback and then render and load the rendered file which again will give a break in playback.

This all just sound like putting more and not necessary load on both CPU and hard drive. Also if this was to render in the background it would also mean that Cubase has to load a new instance of every plugin on that track to use for rendering while using the original for live playback.

Sorry, but to me this sounds like an awful idea and not even sure it would be possible. If added then by all means this should NOT be default behavior. Considering modern CPUs, it is really not that often you would need to freeze a track, maybe some VSTi but not audio tracks. If you need to freeze just hit the freeze button and wait those few seconds it takes to render the file.

Your right it would have to load a clone of the plungins for a track to render the audio in the background. It could do it without using much CPU it would basically take a parallel process.
Maybe it can’t be done yet… I think any modern computer would handle it.
Perhaps the software is not there.

I do think your looking at it too much like freezing is now.

There’s no reason for there to be breaks in playback.
When the rendered file is done it could be cross faded in.
The plugins in the visible track could be internally bypassed.
No reason to unload them. Vst3 doesn’t use CPU unless audio passes.

I run out of CPU all the time , have to freeze and render.
I do a lot of my processing in groups, which aren’t freezable.
It takes time to manage and it’s a work flow killer doing/undoing it.

Honestly I can’t wait for the day you can take every part of any project with you on something like a surface and actually work on it.
Sadly that’s still likely 20 years + away (we said that same thing 20 years ago) because as processing power increases so does the complexity of plugins and programs.
It would be awesome if the software made it possible now.

That’s the thing, I never have to freeze anything. Well, maybe some Synths I use for background stuff and FX but i would render those to audio anyway.
With that i don’t want anything to take up CPU cycles in the background, or putting more load to the hard drive.
Some plugins, specially those with very high latency tends to give a short break in sound when bypassed. Also there is still lots of plugins still using VST 2.4.

If you have to freeze and render all the time, maybe it’s time to get a faster CPU instead. I still don’t like this and it’s something i don’t want Steinberg to do.

AFAIK vst3 (no processing when no audio) is a feature of vst3 that is not mandatory to implement.
Having a DOP (direct offline processing) auto running on every track, is close to this FR.
Not a fan of that.

It could totally disable the effects chain.
Then enable it when you select on the channel.
If it took 0.5 seconds to make that happen glitch free before the plugins were actually live you would never notice.

The idea isn’t about using more CPU its about using much less…

Everything including cellphones is multi core now , why couldn’t the offline process of auto freeze be confined to 1 core or a % of the total cores.
I don’t buy the hard drive issue either, not anymore , audio streaming is nothing to modern drives.

You will use more CPU while it’s running in the background and I’m not interested in that. It will also put more load to hard drive as it needs to both read and write files in the back ground.

Either way, I’m voting against this, bad idea imho and not needed. You already have the tools you need to free up CPU power.

Sorry I really don’t agree.
I do a lot the processing in groups, I think most serious users do. That can’t be frozen.
Freezing single tracks isn’t enough with a mid-range CPU. It doesn’t free up enough.
It is also rediculious to render it to audio manually if there is a possibility you need to go back and change a part in a group. It’s very time consuming to undo and you end up with a mess of tracks.

I don’t really care if the flexfreeze idea renders all the time.
It would be the best way but not the only.
It could be implemented to work whenever the project is stopped, even for a few seconds.
God knows we all spend a huge amount of time tweeting things with the playback stopped and cubase open .

It really would save huge on CPU for those of us who process in groups especially. Without thinking about it!
Why do I need a high end CPU to do audio in 2018? It’s honestly ridiculous.
Think of the $$ 1000’s the users would save in CPU equipment and Electricity.