My gripes about track freezing

[Frippertronix]

Seems like it shouldn't be that hard to offer the use of volume/pan and to add more plugs if wanted after you freeze a track. I don't freeze tracks to set them in stone (I render for that), I freeze them to get a bunch of processing out of the way temporarily, but it sure would be nice to continue to fiddle with levels, etc., after a track is frozen.

Just my $.02 U.S.

[semiquaver]

Heres a workaround:

route your track to a blank neighboring track. place an empty midi clip in that track. Now when you want to "freeze" just render the destination track and mute the source track - go ahead and add plugs to the destination, whatever. To unfreeze just select the rendered clip and control-m to delete source and unmute your track. You then have the option of keeping your new plugs - copying them to the source track or deleting them. With vsti tracks there is even a cuter way to do it: render the track and import the rendered file into the same track on top of your midi clips. Then just mute the filters to hear your rendered audio - turn the vsti back on to hear the midi through it.

[mandolarian]

That is just too devious. Thanks, Semi! I have to try that.

[Frippertronix]

Yes, thanks for the tip!

Dave

[Lunch Money]

Just a quick word of defence, though--

In order to accomplish what you'd want to do, there would have to be a trade-off:

The way it's implemented now, ALL frozen tracks end up in one file. Hence, no volume/pan, but as a result you TRULY save CPU and HDD usage.

To do it your way, each frozen track would basically have to be a render. Which is fine, and most of us have systems that wouldn't hiccup with a per-track file instead of a "collective" file. It would, however, save LESS CPU and HDD usage, which could theoretically cripple large edits.

Until there's an option on freeze behaviour (picking per-track instead of per-edit) and I HAD to choose one or the other, I'd choose the current implementation because in terms of workarounds it's much easier to use render as a workaround to accomplish the same goal as a per-track freeze than it would be to use render as a workaround to freeze multiple tracks, if you catch my meaning.

Ideally, there would be the option, though.

Greg

[haydxn]

yeah, ideally there would be an option.

as it stands for me it's essential that freeze behaves like this to save on HD abuse (i get that long before CPU overload). if you want to do it the other way RenderAndAdd is exactly that but with an extra track appearing. yes it's a workaround but you can't escape the fact that it does exactly the same thing. but freeze needs to maintain it's current form, even if it adds a different version, because there are those of us for whom it is essential.

[braj]

How about a per-clip freeze? That would be a better alternative to adding a normal per-track freeze IMO and you could use the current freeze along with the clip freeze. Of course you could freeze all the clips in a track. This way if you freeze midi clips you would still have all the regions for each clip as separate entities to move wherever you need them. It would make using per clip effects really useful because you could throw an effect on a clip and freeze it right away.

I dunno, once again Live has inspired me. I think this would work really well in Tracktion.

[semiquaver]

Whats wrong with rendering clips?? - it makes no sense to freeze a single midi clip - what happens to the other midi clips on the track? is the VSTi disabled ? As I suggested on another thread - just render and bring the audio into the same track as the midi - must the vsti to hear audio, unmute to hear the midi.

[braj]

Whats wrong with rendering clips?? - it makes no sense to freeze a single midi clip - what happens to the other midi clips on the track? is the VSTi disabled ? As I suggested on another thread - just render and bring the audio into the same track as the midi - must the vsti to hear audio, unmute to hear the midi.

It does make sense, but I don't know what would happen to other midi clips on the track, maybe they still drive the VSTi. VST is auto-muted to hear audio, unmuted to hear midi? I dunno. Live will apparently be able to do this, so why not T2?

Anyway, it's not like I'm counting on it or anything. Just another cool idea inspired by Live.

[semiquaver]

T and live have different architechture - T has tracks that can house overlapping audio and midi clips. This is a very flexible and interesting setup allowubg you as it does to toggle between hearingv a vsti and hearing audio as I described above - you can also make a rack that routes midi to a vsti and passes audio through so that you could monitor both. T is very simple and flexible here and lets you use it in a variety of ways - you can do whazt you are after in the current setup.

[braj]

You can freeze midi clips to audio?

The reason I like Live's upcoming clip freeze is that the alternative render in T would make every clip in your track one long audio file, which you manually have to go through and edit out the silent space to be able to move the audio around. And once moving the audio around, if you want to manipulate it further (unfreeze it) you have to go back to the original midi file with everything where it was before your (possibly) weeks of work, and then do it all over again.

I don't know if it would be easy or possible to implement in T, but as a feature clip freeze would rock hard IMO. I'm thinking it may not be possible though since Live uses the session view to manage clips in a way that T can't. So, um, nevermind. I guess.

[semiquaver]

Braj: you can render midi clips to audio. Then import them on top of the midi clips then move them together. Toggle the VSTi to hear pre or post frozen tracks. Or bring them onto an adjacent track - it is still easy to move them together. You can also easily tweeze either sound and re-render or store different versions in your project file. So what's the problem ?

note: you like "Live's upcoming clip freeze". In fact you like the sound of Live's upcoming clip freeze - you have yet to try it in practice.

[braj]

Braj: you can render midi clips to audio.

You can render midi TRACKS to audio, not individual clips. What you are suggesting still has all the limitations I mentioned. You have to go back and manually hack apart a rendered track to rearrange it. Unless I'm missing something.

[semiquaver]

To render a MIDI clip to audio, select it, choose export>audio file and check "only render selected clips".

If you are wanting to render a bunch of clips as seperate audio clips in one operation you're right T wont do that (it would be nice though).

But I don't see the premium on moving frozen clips around - why not just re-render or move audio and clips together?

[haydxn]

no you can render clips to audio. it's just called export. and before you go 'aarrgh!' it's not exactly a much more complicated procedure. especially if you keep a file browser behind tracktion open to the folder you'll be using for your current project's audio.

1- click the clip
2- click export
3- check 'only render selected clips' is on
4- click ok
5- import the file (either press A and navigate, or switch to the file browser and drag the new file into the edit page)