Audio mixdown as "freeze"...

[Trancit]

I selected a part and chose Mixdown Audio from the file menu...
Next window I chose audio file and create new part using result...

Everything went fine, but the new created track with the rendered audio file was hearable but routed to nothing not even to the master, I guess it's automaticly routed to the ASIO outputs of my soundcard...

1. Wouldn't it not make more sense to autocreate a rack, where the new track is routed to...If I choose create new part using result, it is clear, that I want to work further with it in my project, so a new rack would be necessary, imho...
Especially for the intend that I want to mixdown to audio later including the new audiopart...

2. What is recorded??? The output of the rack to which my sequence is routed to or the master output??? If the master is recorded, it's quite long-winded to bypass the master effects chain, isn't it...
If so, is there any other way, e.g. with the new audiorecorder??
If again so, how does it work??? Is there any tutorial (beside this little quickview video)???


Trancit

[Trancit]

OK, I figured out, how the audio file recorder works...is there any way to do this offline at higher speed, or just realtime???


Trancit

[Trancit]

Again more from me

The mixdown audio records the master output, right??
To bypass the Master chain, I have to set the output of the rack to Audio Out instead of master, right???
Or use in realtime the audiofile recorder, right???

One other thing:

If I have recorded my file direct from a rack only to "freeze" the included synth, I would like to route the recorded file direct back to this rack, to use the adjusted sends for e.g. delay and reverb, but if I do so, I hear nothing, because the VSTi is still inserted...is there any way, to do so easily???

Questions, questions, questions

Trancit

[janamdo]

I selected a part and chose Mixdown Audio from the file menu...
Next window I chose audio file and create new part using result...

Everything went fine, but the new created track with the rendered audio file was hearable but routed to nothing not even to the master, I guess it's automaticly routed to the ASIO outputs of my soundcard...

1. Wouldn't it not make more sense to autocreate a rack, where the new track is routed to...If I choose create new part using result, it is clear, that I want to work further with it in my project, so a new rack would be necessary, imho...
Especially for the intend that I want to mixdown to audio later including the new audiopart...

2. What is recorded??? The output of the rack to which my sequence is routed to or the master output??? If the master is recorded, it's quite long-winded to bypass the master effects chain, isn't it...
If so, is there any other way, e.g. with the new audiorecorder??
If again so, how does it work??? Is there any tutorial (beside this little quickview video)???


Trancit

Suppose you start with a source track and mixdown this track, than when you open both screens: the composingscreen with the two tracks and the modular (session)screen)....than when you select the two tracks in the composingscreen(toggle on/off)than than this is also reflected in the modular area screen

From this information you cannot deduce the modular logic ?

[mutools]

I selected a part and chose Mixdown Audio from the file menu...
Next window I chose audio file and create new part using result...

Everything went fine, but the new created track with the rendered audio file was hearable but routed to nothing not even to the master, I guess it's automaticly routed to the ASIO outputs of my soundcard...

That's strange. The resulting audio part should be routed directly to the Audio Output module. I doublechecked mixing down a single sequence part and it all worked fine here.

1. Wouldn't it not make more sense to autocreate a rack, where the new track is routed to...If I choose create new part using result, it is clear, that I want to work further with it in my project, so a new rack would be necessary, imho...
Especially for the intend that I want to mixdown to audio later including the new audiopart...

The rendered audiopart is on a track targetting the audio output module.

If you want to route it to a new rack, right-click that track -> Choose Target Module -> New Module In New Rack and press [Esc] when the module list pops up, it will target a new empty Rack.

2. What is recorded??? The output of the rack to which my sequence is routed to or the master output???

Mixdown renders everything up to the final audio output(s).

That's also why a new track/part using the result is routed to that audio output.

If the master is recorded, it's quite long-winded to bypass the master effects chain, isn't it...

Not sure if i understand. Can you please explain.

If so, is there any other way, e.g. with the new audiorecorder??
If again so, how does it work??? Is there any tutorial (beside this little quickview video)???

What's wrong with the tutorial video?

[mutools]

OK, I figured out, how the audio file recorder works...is there any way to do this offline at higher speed, or just realtime???

The audio recorder works real time.

[mutools]

Again more from me

The mixdown audio records the master output, right??
To bypass the Master chain, I have to set the output of the rack to Audio Out instead of master, right???
Or use in realtime the audiofile recorder, right???

Ah, ok, got your point now.

Answer = Yes.

(in the future there may come more options. also a comfortable 'freeze' system is on the wishlist)

One other thing:

If I have recorded my file direct from a rack only to "freeze" the included synth, I would like to route the recorded file direct back to this rack, to use the adjusted sends for e.g. delay and reverb, but if I do so, I hear nothing, because the VSTi is still inserted...is there any way, to do so easily???

Not yet.

I agree all these steps should be part of a comfortable freeze system.

[robenestobenz]

Yay for a convenient freeze system. And then multicore, so we don't need to freeze!

Not that we ever ask too much of the one talented guy running the show, eh!

[Trancit]

I selected a part and chose Mixdown Audio from the file menu...
Next window I chose audio file and create new part using result...

Everything went fine, but the new created track with the rendered audio file was hearable but routed to nothing not even to the master, I guess it's automaticly routed to the ASIO outputs of my soundcard...

That's strange. The resulting audio part should be routed directly to the Audio Output module. I doublechecked mixing down a single sequence part and it all worked fine here.

Yes that's true...it is directly routed to the Audio Output...the question is: why??? If I let MU.LAB autoimport an rendered file, I do so with the intention, to let the file be part of the whole project (again), which ends for me (because after this should not exist any further editing) at the Master chain/ rack, however you like to call it...

For me and my work, the absolute final instance in a mix is a brickwall limiter at the end of the master chain, which is "normally" placed in the Master Rack ( in MU.LABs language)...

Why is the rendered file is autorouted behind my master and behind my final mix instance???

I know, I can change the routing, but again, for me the current routing doesn't make any sense.

Am I so wrong here???

2. What is recorded??? The output of the rack to which my sequence is routed to or the master output???

Mixdown renders everything up to the final audio output(s).

That's also why a new track/part using the result is routed to that audio output.

Again, that makes no sense... Imagine you want to freeze a CPU hungry leadsynth by mixdown or recording and autoimproting the file...

The sound is autorouted to audio output and plays side by side with rest of the mix...how shall I integrate it into the mix, if it is routed in this way, how shall I prevent clipping, if the brickwall limiter affects only the rest of the mix but not the audiofile...the only way is to reroute this audiotrack...

It should be the other way round: before mixdown, there should be an otpion to autoroute the involved tracks directly to the audio output ( to be not affected by the master chain while mixdown) and after mixdown back to master again...
Then, the new audiofile should be autorouted to a new rack before the master rack...
That would make more sense and is the way I know from every other host I ever used...

If the master is recorded, it's quite long-winded to bypass the master effects chain, isn't it...

Not sure if i understand. Can you please explain.

Hope it is clearer now

If so, is there any other way, e.g. with the new audiorecorder??
If again so, how does it work??? Is there any tutorial (beside this little quickview video)???

What's wrong with the tutorial video?

Nothing wrong, but not a selfexplaining tutorial...

But it was easier by trying it than I thought before

[Trancit]

Not yet.

I agree all these steps should be part of a comfortable freeze system.

Would be wellcome, but multi-core support is still number one...it would make "freezing" less important...

[liquidsound]

Would be wellcome, but multi-core support is still number one...it would make "freezing" less important...

Until you get going with some instances of u-he's ACE!

[mutools]

Yay for a convenient freeze system. And then multicore, so we don't need to freeze!

One doesn't exclude the other because it really depends from system to system.

Anyway, there are 3 wishlist items about CPU handling:

* Optimize MU.LAB's modular system (SMA, MUX, MuSynth) so it becomes (much) faster. I hope to gain at least 25%. Note that VST plugins themselves won't benefit from this as they're 'black boxes' to a host application.

* A comfortable freeze system

* Multicore support

I'm quite convinced the first item is the first one to be done. Also because it fits in the plan to release MUX as a VST plugin.

[mutools]

Yes that's true...it is directly routed to the Audio Output...the question is: why??? If I let MU.LAB autoimport an rendered file, I do so with the intention, to let the file be part of the whole project (again), which ends for me (because after this should not exist any further editing) at the Master chain/ rack, however you like to call it...

For me and my work, the absolute final instance in a mix is a brickwall limiter at the end of the master chain, which is "normally" placed in the Master Rack ( in MU.LABs language)...

Why is the rendered file is autorouted behind my master and behind my final mix instance???

I know, I can change the routing, but again, for me the current routing doesn't make any sense.

Am I so wrong here???

No, not at all, i think what you say is very logical and a typical workflow.

Mixdown renders everything up to the final audio output(s).
That's also why a new track/part using the result is routed to that audio output.

Again, that makes no sense... Imagine you want to freeze a CPU hungry leadsynth by mixdown or recording and autoimproting the file...

The sound is autorouted to audio output and plays side by side with rest of the mix...how shall I integrate it into the mix, if it is routed in this way, how shall I prevent clipping, if the brickwall limiter affects only the rest of the mix but not the audiofile...the only way is to reroute this audiotrack...

It should be the other way round: before mixdown, there should be an otpion to autoroute the involved tracks directly to the audio output ( to be not affected by the master chain while mixdown) and after mixdown back to master again...
Then, the new audiofile should be autorouted to a new rack before the master rack...
That would make more sense and is the way I know from every other host I ever used...

MU.LAB's modular design allows for many possible routing options and the setup you describe is certainly not the only one used.

I'm not sure if simply routing the selected parts to audio out is a good option. What about automation parts that target an (embedded) module? And i'm sure there are more aspects about a good freeze system. (as that's what we are talking about )

My first question about freezing is: What should be frozen: Parts or Modules? That's an essential question and one of the first thigs to be researched in this specific topic.

Imagine a bassline sequence part routed to a rack with a bass synth.
Below that part is another part with automation to a certain submodule-parameter of that bass synth. Now if i select the bass part and freeze it, then the automation would not be included. This is something to think about.

Another aspect: Imagine a couple of parts targetting different modules which end up together towards the same fuzz box plugin. Now it's typical that the resulting output sound of a fuzzbox is directly dependent on the input level. Now if we mixdown one input part of the fuzzbox, and then mix the rendered/frozen version together with the remaining fuzzbox parts, chance is high it won't sound the same. So maybe we should put the freeze functionality at the Module level? So in this case we can freeze the fuzzbox and then everything that comes into the fuzzbox (including any (upstream) automations etc) will be included. Also something to think about.

What's wrong with the tutorial video?

Nothing wrong, but not a selfexplaining tutorial...

Please tell me: How can the tutorial be made more selfexplaining?

[Trancit]

MU.LAB's modular design allows for many possible routing options and the setup you describe is certainly not the only one used.

I'm not sure if simply routing the selected parts to audio out is a good option. What about automation parts that target an (embedded) module? And i'm sure there are more aspects about a good freeze system. (as that's what we are talking about )

My first question about freezing is: What should be frozen: Parts or Modules? That's an essential question and one of the first thigs to be researched in this specific topic.

Imagine a bassline sequence part routed to a rack with a bass synth.
Below that part is another part with automation to a certain submodule-parameter of that bass synth. Now if i select the bass part and freeze it, then the automation would not be included. This is something to think about.

Another aspect: Imagine a couple of parts targetting different modules which end up together towards the same fuzz box plugin. Now it's typical that the resulting output sound of a fuzzbox is directly dependent on the input level. Now if we mixdown one input part of the fuzzbox, and then mix the rendered/frozen version together with the remaining fuzzbox parts, chance is high it won't sound the same. So maybe we should put the freeze functionality at the Module level? So in this case we can freeze the fuzzbox and then everything that comes into the fuzzbox (including any (upstream) automations etc) will be included. Also something to think about.

I think the most typical freezing option would be to freeze modules...
I personally use freeze for two demands:

1. Freezing a very CPU hungry synth like ACE, which is often playing only one sound (lead/ pad...whatever)

2. Freezing a Plugin to free up RAM (like BFD/ Superior Drummer/ Omnisphere or a Sampler using a very big sampleset)

For both demands, all included parts and automation routed to this Synth/Sampler should be included in the mixdown...
For both demands, processing should be disabled (or an option, if I like to autodisable or not)
Especially for number 2, at least an option to unload the plugin is necessary...

A very powerfull option would be, leaving the midi and automation parts acessable, that you can further edit them (in this moment of course with no effect of the sound), that you can simply refreeze the changes, without the need to unfreeze before...very handy for projects, which plays anyway already at the limit...
Because of all the flexibilities of a modular system and if this freeze cannot be used for more complex routings, users can still use the audio recorder functions, if this freezing fits in this situation...

I guess other people have other/better ideas too

Please tell me: How can the tutorial be made more selfexplaining?

First for me, is without hearing anything in a video it is harder to follow...we are talking about recording audio and I hear ...nothing.
Second...it is easier to listen to spoken explanations than only to read a lot of screenshots, without seeing any movement, stopping, because it was to fast, reading again...which button??? Aah, ok, this one...you know, what I mean???
Third, you tell, that you get a message, where the audio goes to, if starting from a new project, but what are the other ways??? How can I change this???

Where to you get this record options thingy from...is there an entry, a button or...

The single options in the audio recorder are not explained, I think it is an really cool feature, that you can choose any module from "Record from" and it is autoconnected...this would have covered as well needs, that don't want to record from outside MU.LAB...I don't do this, I want only to record from inside...

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

That were my impressions on it...sorry

[mutools]

I think the most typical freezing option would be to freeze modules.

Although i really did not yet research this deeply (otherwise freezing would be close to implementation of course), i also think the solution is freezing modules. Sounds the most logical to me, at first sight.

A very powerfull option would be, leaving the midi and automation parts acessable, that you can further edit them (in this moment of course with no effect of the sound), that you can simply refreeze the changes, without the need to unfreeze before...very handy for projects, which plays anyway already at the limit...

Yep, +1

Please tell me: How can the tutorial be made more selfexplaining?

First...

Second...

Third...

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

Thanks a lot for your feedback on this!

In fact i also had a feeling that that video was not yet perfect.
Part of the reason is because i was still strugling to find the best workflow for creating such videos, but ran out of time at that point. FYI: It's the intention to create many more of these videos. As messaged before on the forum, i keep the docs brief and essential for good reasons. They're more like a reference guide. I would like to enrich them with many MU.LAB: How To videos on YouTube. (as time allows)

Last week, i invested quite some time to find a good workflow and i think i'm there Soon i'll test the new workflow by remaking that "Multitrack Audio Recording" video. Then your feedback (and some other aspects i wrote down) will be taken into account.