Audio mixdown as "freeze"...

[pljones]

Sounds right to me.

[TheGuysanIdiot]

+1

OZ

[liquidsound]

Yes. This is what I was trying to say.
+1

[MuTools]

For me, this video was not selfexplained, because it assumes, you know everything about how to route this up...

In fact i also had a feeling that that video was not yet perfect.
Soon i'll remake that "Multitrack Audio Recording" video.

That tutorial video will be remade once the next version is out for i expect too many changes in the modular editor and then the tutorial video would look outdated again. So better to recreate it after the next version out. And the current tutorial video is certainly helpful for a couple of months

[robenestobenz]

One feature that would make rendering parts to save CPU a bit faster would be if there was a way to turn off all modules in a rack in one go -- either from a context menu, or a power button on the rack itself.

[The Kob]

One feature that would make rendering parts to save CPU a bit faster would be if there was a way to turn off all modules in a rack in one go -- either from a context menu, or a power button on the rack itself.

that gets my vote. like the 'stand-by' button
would this be fully automatable too so that unused processes can toggle on/off during playback?

.

p.s. dunces corner: how does freeze differ from process off?

[robenestobenz]

One feature that would make rendering parts to save CPU a bit faster would be if there was a way to turn off all modules in a rack in one go -- either from a context menu, or a power button on the rack itself.

that gets my vote. like the 'stand-by' button
would this be fully automatable too so that unused processes can toggle on/off during playback?

.

p.s. dunces corner: how does freeze differ from process off?

Freeze invisibly creates a rendered version of a sequence with processing applied and then disables all the plugins. This then allows you to hear the processed audio without the CPU cost.

It's not well suited to a host with such flexible routing as MuTools though, because of the number of routing permutations.

[The Kob]

It's not well suited to a host with such flexible routing as MuTools though, because of the number of routing permutations.

ta,
yes difficult if you have multiple sends or rely on data/noise from another route for something like a vocoder.
could you not determine what the dependancies are and where they are dual-duty and then create duplicate 'images' of the process you need to freeze and keep active.
.
i know this sounds like you are adding load (you are locally) but it might still save processing overall?

[robenestobenz]

It's not well suited to a host with such flexible routing as MuTools though, because of the number of routing permutations.

ta,
yes difficult if you have multiple sends or rely on data/noise from another route for something like a vocoder.
could you not determine what the dependancies are and where they are dual-duty and then create duplicate 'images' of the process you need to freeze and keep active.
.
i know this sounds like you are adding load (you are locally) but it might still save processing overall?

There was some discussion about this earlier in the thread. It does just seem a bit impracticable to implement.

Most hosts have their inserts embedded into a track, which simplifies things enormously as far as freezing goes. You freeze a track you know is paining your processor and that's it.

In MuLab, you can't really do this consistently, because it uses the buss/rack model to begin with and so multiple tracks can share racks. So freezing single tracks becomes impossible if they share destinations, to take example of just one problematic routing config. To do things consistently you have to freeze at the module level, which muddies the connection between the action of freezing and what gets frozen because you're doing it from stages in the signal chain rather than the actual musical material itself. Much less clear than the "what track do I wanna freeze" approach you can use in hosts with track-embedded inserts.

So, because of all this, I think Jo's decided that optimisation and multicore R&D are better uses of his development time than trying to squeeze freezing into a system where it doesn't really fit so well...