Conversation: Freezing Tracks "workaround"

[Taron]

The One Synth Challenge brings together a pretty diverse crowd, illustrating issues of all sorts. One of those issues was the processing troubles with hungry VSTs. DAWs like Cubase offer a way to disengage such plugins, probably sampling the whole part of certain plugins and replacing the track temporarily with this sample.

I totally see how that can be convenient, no doubt, but Mulab as "Render Selected Parts...", which one can easily use to do the same thing with a little extra effort of dropping the resulting sample into its own lane and muting the original tracks temporarily. With the new bar on the right side to show Samples amongst other assets, it's so very easy to handle that.
The cool part there is that you can do a whole bunch of tracks at once that way and if you were to stuff those tracks into a parent track, it would be easy to mute them all at once, too.

Naturally, Mulab would look quite a bit sexier, if it had a [FREEZE] toggle on a rack (yes, "rack", because you can have countless tracks using one rack, which is probably why it's so ugly to figure out how best to implement it?!). But if you asked me...hmm...that would drop rapidly to the very bottom of my wishlist.

Most of the time having to freeze a track comes from having a computer that goes to its knees. I'm sure it can be used creatively in many other ways, but that's exactly what I'm getting at; Rendering Selected Parts gives you all the perks of freezing tracks that go beyond relieving the machine.

I'm interested in hearing, if I'm missing something here, though! Thus, don't hold back and spank m...no wait, that comes out wrong...don't hold back to show me the way!

[MuTools]

I agree that with the current features the user can already bypass the situation where the computer is not powerful enough to render the complete song in realtime. But atoh i understand the users who request a more simple and easy "freeze" function. But due to the open and versatile structure of MuLab it's not easy to implement that in a way that makes sense. I also think the freeze function should be more rack/module based than track based. Kind of "Freezer" module that will (semi-)automatically render+record all incoming audio and play it back accordingly. A bit like the Audio Recorder module, but then evolved to also do the rendering and playback. Then there still is the job of deactivating the upstream plugin modules so to free CPU resources. That's another challenge. Anyway, by being able to choose at what point in the signal flow you insert a Freezer will match MuLab's flexibilty. The disadvantage would be that there still would not be a simple sexy freeze button. The advantages and disadvantages of flexibilty.

[bibz1st]

What does 'freezing' do that rendering to a wav doesnt ?
A friend has Cubase and on occasion we have used the freeze function but I am unsure what it did other than create a wav of the particular plugin that was 'not behaving'
You can 'unfreeze' it but is that not the same as opening up the rogue plugin again ?

[Taron]

Exactly!
Ah...to both of you, of course!

[MuTools]

What does 'freezing' do that rendering to a wav doesnt ?

The difference is in the ease-of-use. Freezing indeed is very similar to rendering but should also support easy re-rendering and disabling/enabling the relevant plugins. So it's about less steps to achieve the freeze and free CPU.

[Taron]

Your funny sometimes, Jo!
...note to all those, who are trying to argue in support of Jo's efforts: Stay away from rhetorical questions and/or sarcasm!

Yep, yep, the sexy freezing button would surely be a major convenience for those who need freezing.

[MuTools]

Your funny sometimes, Jo!

Thx, but don't know why. Pls explain.

[Taron]

Now I'm baffled...am I now about to fall for some sarcasm?
...just in case: Of course we know that freezing/unfreezing is a very convenient feature.
I still think that most computers now are so powerful, that the need for it is fading. Having the option of an alternative seems totally adequate to me, considering the effort it would demand of you to implement it. It seems complicated to me and I can see countless follow-up troubles with each fix. It's the proverbial "can of worms" or "Pandora's box". Without having to think too much about it I can already see a number of issues that could arise:
- Freezing a rack has to create a "temp track" for the resulting sample, most likely. This track probably has to be locked somehow, to prevent anyone from messing with it and then losing it as the "unfreezing" should remove it again.
- Freezing a rack has to locate all the tracks from all the direct members within the rack, but has to make certain distinctions, like with "send to..." slots.
- What if someone wanted to freeze an effects rack? Will you know if a rack contains an instrument or is just a "bus"?
- The diverse power of MUX may allow wicked routing gimmicks that could cause trouble?!

So...this all appears to me like "hell" if there was one, haha. And it's probably just the tip of the iceberg. And by the time your done, there's no old machine left that would force anyone to ever need freezing again, haha.

There are far more exciting features you should lean on and which should cause far less trouble! My advice would be to do the Metronome Accent for the first Beat real quick or even a custom Metronome pattern!?
Many new eyes are on you right now and it's a great moment to do your thing!

[MuTools]

Of course we know that freezing/unfreezing is a very convenient feature. I still think that most computers now are so powerful, that the need for it is fading.

I don't think so as the more powerful computers get the more complex and cpu intense algorithms will be used, so the need for freezing will still stay. Another thing: Maybe many users are still creating/producing using 44.1 or 48 kHz but in fact the creating/producing should be done at the double, only the final rendering should go to 44.1 or 48 kHz. So double samplerate = double CPU usage.

I can already see a number of issues that could arise:
- Freezing a rack has to create a "temp track" for the resulting sample, most likely. This track probably has to be locked somehow, to prevent anyone from messing with it and then losing it as the "unfreezing" should remove it again.

That's not how i see it (at this point, cause it's still unfinished thinking). The Freezer module would only affect the signal flow in the sound engine, not in the tracks. For example a cpu intense synth track would still be sending the notes, but the target synth is kind of muted and the freezer below it will playback the rendered audio. Just a coarse concept. Maybe i'm missing something.

- Freezing a rack has to locate all the tracks from all the direct members within the rack, but has to make certain distinctions, like with "send to..." slots.

That's why i would let the user decide at what point to insert a Freezer.

The diverse power of MUX may allow wicked routing gimmicks that could cause trouble?!

Possibly indeed. It surely needs more thought.

[Taron]

So, you're saying that you are on 96khz when you work with MuLab? I wouldn't even get to freezing anything as everything would be frozen already, hahaha....
Nah, I am now permanently on 48khz, which works fantastic. When I render my stuff, though, I sometimes go to 96khz at 32bit to make sure I get the best quality rendered and then down convert elsewhere with proper dithering. Seems to me like a decent habit.

OH, but one little thing. It might be nice to be able to drag a sample into the tracks area and enable for it to add a track, just like with racks or synths!

[MuTools]

So, you're saying that you are on 96khz when you work with MuLab?

No i'm not saying i am, but i would do it if i could. In a couple of years i guess that will be no prob at all anymore, CPUs will keep on getting faster, at least via parallelism. (and maybe by "freezing" cpus, i mean really the low temperature thing, not the freezing of this topic)

OH, but one little thing. It might be nice to be able to drag a sample into the tracks area and enable for it to add a track, just like with racks or synths!

That's already supported. No?

[Taron]

Nope, when I try to drag a sample from the right hand bar into the track head area on the left, it won't add a track. You can drag it onto an existing track lane, but that means you have to make a new track first.

[MuTools]

You have to drop it in the time-line area not on the [+] button, otherwise how would MuLab know at what time the new part should be? You can drop it below the existing tracks to create a new track.

[MuTools]

PS: Ah well on the [+] button could create it at 1.1.0000 of course. + on wishlist.

[Taron]

There you go! That would be perfect!
Just for clarity's sake, you know.

But, yeah, I totally didn't realize that it already adds a track for itself when you drop it on the timeline!
thanks for the info!