Freeze funtion

[Paul]

I'm not trying to turn Metro into Logic or DP , but a freeze function would be a very welcome addition. I know that you can now render a track, which sort of leads to the same result. I do however feel that freezing/unfreezing would be much more practical.

[Jerm]

How exactly would you like this to work

[Scoot]

Is Paul asking for a disabling feature whereby the track remains viewable/available but is not taking up CPU till the track is activated again? I suppose it would have to disable plugins unique to that track as well.

A 'D' button next to R M S with a cyan/blue light showing in the tracks window column would be a good way to implement it for the user.





Following on from Real vs Apple ipod debate, the app should be called "Logical Metro DP: reverse engineered".

[Paul]

Scoot is right. I would like a button which disables the track and releases the cpu (maybe even clears the memory that a plugin is using; e.g. a sampler ). The advantage over rendering would be that unfreezing the track would make it available for editing again. I think that the frozen track would play back a rendered version from the hard disk. This is a temporary file which would be erased when the track is unfrozen. I'm not sure how or if this would work with multi timbral plugs.

[Jerm]

Yes, that makes a lot of sense. I think the plug-in would only be disabled if there are no more references to it. So in the case of a multi-timbral plug-in, it would be disabled only when it has no track or aux buss references to it.

[Paul]

So, the question is... is it a possible new function of Metro?

[Scoot]

How much of a freeze/disable function does the mute button do?

Jerm - In other posts you mention that not having record enable on any track stops the record engine? from being active taking up CPU. I was wondering if mute gives similar savings.....afterall it doesn't playback the track muted.


Further to the original message -
I suppose a disable button would also need to hide the waveform of the track disabled for further benefit......maybe filling the track area with a colour. I haven't actually seen any frozen apps in practice so I don't know how it is elsewhere.

(The only frozen apps I see contain the dreaded apple pinwheel and usually a force quit ).

[Jerm]

So, the question is... is it a possible new function of Metro?

Oh, Definitely

[Jerm]

How much of a freeze/disable function does the mute button do?

None. However archive is very similar to disable. Essentially freeze would be very similar to render although the resultant output would be placed on the original track. There are several details to work out.

On the first implementation which will be when I get enough time, I do not think there will be a column in the tracks window but rather it will work similar to archiving.

...was wondering if mute gives similar savings.....afterall it doesn't playback the track muted.

No. Muting does not do anything to the processor load. The reason why it doesn't is because we want mute and unmute to be responsive. It should be immediate.

I suppose a disable button would also need to hide the waveform of the track disabled .....

I think freezing will essentially render the track and convert its type to audio and also disable any plug-ins that go out of scope. Unfreezing will delete the audio file and convert the track type back to Soft-Synth and enable any plug-ins that come into scope.

I think that should work.

[Scoot]

Unfreezing will delete the audio file and convert the track type back to Soft-Synth and enable any plug-ins that come into scope.

I think that should work.

Cool.
Time for a dum question.....

If metro writes the track off to audio, when it comes to unfreezing, how does the audio know it belongs to a soft synth and midi data? Do you save a preset/file with it to mount things back the way they were?

[Jerm]

If metro writes the track off to audio, when it comes to unfreezing, how does the audio know it belongs to a soft synth and midi data? Do you save a preset/file with it to mount things back the way they were?

It knows the audio belongs to the freeze track because the freeze bit is set in the track.

However if the frozen track is saved in a Metro document to the hard disk then the frozen audio will be marked as undeletable and the user will have to manage the hard drive space by deleting it manually. An alternative would be to make the frozen track's audio file un-editable and not save it as a standard AIF file (so other programs cannot access it). Which is better

[Scoot]

Making it uneditable seems like a plan to me.
Otherwise you'd be trying to locate tracks they may be like a needle in a haystack and remembering to delete them off the disk.

OK.....I can't use them in other apps, but all I need to do is unfreeze them and they return to be edited off to disk.

It's probably best to stay in the environment as much as possible.....and stay out of the finder.


I would suppose freezing would be used (most of the time) for a temporary situation to try different things out......and see what works better etc.

[Paul]

Any news on the development of the marvelous freeze function?

[Jerm]

It is not on the front burner yet. There are still some details to be worked out.

In the meantime, and please tell me why I am wrong, it is very easy to mix multiple tracks into a single audio stream and then archive the original tracks. This is actually faster than freeze which would have to render each track individually.

[Jerm]

Any news on the development of the marvelous freeze function?

The freeze function is completed and is working quite nicely in Metro 6.3. While it does not remove the plug-in entirely it does bypass plug-ins on aux busses when there are no references to them. This greatly decreases CPU for some plugs such as SampleTank 2. If the plug-in is a track-insert, it does not matter anyway.

The archive menu has been renamed archive/freeze and there are new options for freeze, group freeze and thaw. Group freeze is the only remaining option that is not fully implemented at this point. It will do a sub mix and then archive the tracks creating a single stereo track. This will be a fast way to get a lot more CPU. Right now freeze does an internal render for each track. It is already optimized to minimize the number of passes required to produce the audio. If tracks are assigned to different soft-synths then they can all be rendered in a single pass. Group freeze will do an internal mix-tracks so will always be a single pass.

Sound good?