Freeze track revisited

[SparkySpark]

Hi,

Lately, I have been exploring granular synthesis more. That brings more strain to my CPU, which makes me looking more into freezing tracks than before (especially the MUX components of MuLab are so efficient so this hasn't been much of an issue for me before!).

The granular synths I use (Pigments and PadShop Pro) also - in part due to granularity - perform differently every time they are played back, so a mixdown creates unpredictable performances. If there would be a Freeze track option, I could just try a few freezes until the synths perform the way I want to, and then use that recording from that point on.

Thus, I have been looking into how to freeze tracks in the best possible way. I found a thread on this (viewtopic.php?f=79&t=476410&p=7350554&h ... e#p7350554 ) . However, I am not really fond of the manner described. First, rendering the track as a MuSampla sample makes it not audible unless the track is played from the beginning (or more precisely, from the point in time at which the parts in question begin). Second, I do find it a bit confusing - when is the CPU as happiest, when is the rack needed, when should I mute what? Well, I _can_ figure this out, and I can of course mix down the entire song, soloing the track in question and then reimport that track into MuLab, but surely there must be a better way?

I do see PiJones's point of modularity, BUT: would it be possible to just implement a "normal" Freeze track and just put an info caption saying "This works best where a track corresponds to a rack" [the normal case]? Or could MuLab sometimes be programmed so that the Freeze track option would only be available (as in not greyed out or so) when there is a 1:1 relationship?

I think this would be very handy now that granular synthesis is coming strong in the software market. (Perhaps a Bitwig user could shed some light on how this is done there, as Bitwig - to my knowledge - is also modular.)

I'd also like to stress that I'm constantly happy with how MuLab performs, 100% stable and the best workflow of any DAW I know of.

[dakkra]

In Bitwig there is no freezing, only bouncing, much like Mulab. It's a controversial topic there as well. The only difference being that Bitwig offers bounce in place, but that also deletes MIDI, which is not desired for freezing. Thus Mulab and Bitwig function similarly with respect to freezing.

https://answers.bitwig.com/questions/14 ... -bitwig-2x -- It's the same in Bitwig 3.1 which I use alongside Mulab 8.4.

A fun note, MUX has it's own grain player: https://www.youtube.com/watch?v=zTRq8trsHgw

Also, as of M8, you can use samples in the arranger via Audio Sequences (similar to Bitwig Clips). Thus you don't have to use MuSampla anymore for parts rendered to a sample. You can drop them right into the arranger, turn off time stretch, and now you have inline audio via a sample.

I hope this sheds some light on this topic. The work around via Audio Sequence isn't so bad IMO (that's how it's done in Bitwig) but I can understand why "true" track freezing would be better for others.

[bbreakz]

Something I would really love to be able to do with the Audio Sequences is to pitch bend the audio inside instead of having to use a sampla. To basically get a tapestop/start style affect. It is easier to do in Bitwig/Ableton

[SparkySpark]

Thanks! Re Dakkra's post: Perhaps an easy way out of this modular (tiny) dilemma would be a right-click on the synth in the RACK (say Pigments), and if it is a standalone VST synth (as in no modular trickiness) it could simply freeze the output of the synth, but still have the RACK perform its duties. In my mind, this would be more optimal anyway, rather than freezing the RACK. Finally, this behaviour (freezing the synth output in the RACK) would make it easier for me as a user to understand what is conceptually going on.

So no fancy solution, just as straight-forward as it can get in the majority of the cases (I'd say a MUX synth wouldn't need freezing for CPU reasons anyway.)

(Wrote RACK in caps to differentiate it from track.)

[pljones]

"a standalone VST synth (as in no modular trickiness)" is still not really good enough a definition. A single event track can feed a module in the modular area that distributes the events across multiple racks, without those racks knowing about it. Would that violate "no modular trickiness" even though each rack had only "a standalone VST synth" in it?

Anyway...
- copy the rack (and routing in and out) then disable the original rack (leaving existing routing in place)
- run the events through the rack down to the first synth entry and create a new audio track with the result
- delete all the entries down to the first synth entry and route the new audio track to the rack
That should do it, right? (Apologies if I'm repeating what someone else already said.)

[SparkySpark]

"a standalone VST synth (as in no modular trickiness)" is still not really good enough a definition. A single event track can feed a module in the modular area that distributes the events across multiple racks, without those racks knowing about it. Would that violate "no modular trickiness" even though each rack had only "a standalone VST synth" in it?

Anyway...
- copy the rack (and routing in and out) then disable the original rack (leaving existing routing in place)
- run the events through the rack down to the first synth entry and create a new audio track with the result
- delete all the entries down to the first synth entry and route the new audio track to the rack
That should do it, right? (Apologies if I'm repeating what someone else already said.)

Hi, Thanks!

Not sure I agree with what you wrote though. OK, I get that it _can_ be circumvented in various ways, but it's not really what I'm getting at (as I'm sure you see). For all I care there could be huge warning sign popup when freezing the synth output.

BTW, if your suggestion is a universal solution (not saying that it necessarily is, but IF it is), then maybe that exact recipe could be precisely the automated steps taken by a "freeze" in MuLab, couldn't it?

I really think this matter can be solved. ...and then MuLab would have a feature that's lacking in Bitwig.