Audio mixdown as "freeze"...

[Trancit]

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.

Could you please consider some little graphic changes as well???

1. The Rack level meters could bear some numbering...
2. The Rack level meters could bear a level indicator (numeric)


BTW, how can the screen of LooxHIQ made a little bit brighter??? It looks goood, but too dark!

[MuTools]

1. The Rack level meters could bear some numbering...
2. The Rack level meters could bear a level indicator (numeric)
BTW, how can the screen of LooxHIQ made a little bit brighter??? It looks goood, but too dark!

All 3 requests can be done by editing the graphics skin.

You could add some numbers onto FullRack.Png and SmallRack.Png.

About brightness: You can finetune the brightness of all .Png files in LooxHiQ if you want.

Or you could contact the skin designer and ask him.

[Trancit]

2. The Rack level meters could bear a level indicator (numeric)

All 3 requests can be done by editing the graphics skin.

You could add some numbers onto FullRack.Png and SmallRack.Png.

About brightness: You can finetune the brightness of all .Png files in LooxHiQ if you want.

Or you could contact the skin designer and ask him.

The numeric level indicator can be inlcuded by the user??? I mean a realtime indicator, which shows the current level of the signal...

In the level meters, there are already little lines...what values do they show??

[robenestobenz]

Interesting. A freeze function is gonna be a bit more complicated in MuLab due to the routing flexibility it offers.

How will you do it when there are shared modules further down in the signal chain of a given part or track? Will it work out the last module/plugin that isn't shared in this chain and turn off processing for all the ones up to that point while the frozen part is playing?

[MuTools]

The numeric level indicator can be inlcuded by the user??? I mean a realtime indicator, which shows the current level of the signal...

Ah no not realtime, i meant some fixed values, if you want that.

In the level meters, there are already little lines...what values do they show??

-6 dB
-12 dB
-18 dB

[MuTools]

Interesting. A freeze function is gonna be a bit more complicated in MuLab due to the routing flexibility it offers.

How will you do it when there are shared modules further down in the signal chain of a given part or track? Will it work out the last module/plugin that isn't shared in this chain and turn off processing for all the ones up to that point while the frozen part is playing?

Euh, i don't know yet. It all needs to be R&Ded.

The only thing i think is that freezing seems to be more related to modules than to tracks/parts. But again, i'm not yet sure, needs to be properly researched.

[Trancit]

The numeric level indicator can be inlcuded by the user??? I mean a realtime indicator, which shows the current level of the signal...

Ah no not realtime, i meant some fixed values, if you want that.

Nope, realtime indicators please!!!

In the level meters, there are already little lines...what values do they show??

-6 dB
-12 dB
-18 dB

Thx...


What do I have to edit, if I like to make the backround of the whole popuplist a little bit more grey, than the pure white list in LooxPhat???

I already made the Populist.png more grey, but this doesn't help with the backround of the entries...

[MuTools]

What do I have to edit, if I like to make the backround of the whole popuplist a little bit more grey, than the pure white list in LooxPhat??? I already made the Populist.png more grey, but this doesn't help with the backround of the entries...

ListItem.Png

It has 3 'states':

top=normal
middle=cursor
bottom=selected

[robenestobenz]

Interesting. A freeze function is gonna be a bit more complicated in MuLab due to the routing flexibility it offers.

How will you do it when there are shared modules further down in the signal chain of a given part or track? Will it work out the last module/plugin that isn't shared in this chain and turn off processing for all the ones up to that point while the frozen part is playing?

Euh, i don't know yet. It all needs to be R&Ded.

The only thing i think is that freezing seems to be more related to modules than to tracks/parts. But again, i'm not yet sure, needs to be properly researched.

how so? Freezing is usually implemented on a part or track level. Technically it's more related to modules, but it's undoubtedly easier to understand from a user's perspective in terms of tracks or especially parts. I think it's quite common to ust want to freeze certain parts at particular points in a track where the CPU load soars, leaving the rest of the track 'live'.

This is why mulab's flexible buss (rack) model complicates things a bit, compared to hosts that have inserts on a per track basis.[/code]

[MuTools]

Freezing per track/part has complications too:

http://www.kvraudio.com/forum/viewtopic ... 73#4143173

(1 sentence removed)

[MuTools]

Ok i've removed the last sentence in my previous post.

Lets keep this an open topic where we can collect thoughts and ideas about a freeze system

Top question currently is: What should be frozen: tracks/parts or modules?

I think it's the latter. But will research it more, step by step.

[Trancit]

My 2 cents:

Track freezing is reasonable for Audiotracks ...
Track freezing for VSTi would only make sense, if all tracks are freezed, which are routed to the module...but would be similar to Module freezing...in this case, all tracks, routed to this module had to be freezed as well...

Track freezing, which doesn't affect all tracks routed to the module, for me makes no sense, because it would not be possible to toogle processing off for that module...so for me, Track freezing and Module freezing should be nearly the same...
Only difference, that's why I would prefer Module freezing:
I guess, there are people, who are using parts on one track routed to different plugins...for workflows like this, Trackfreezing had to freeze all plugins affected by parts of this track...
MU.LAB had, in this case, to research, which other tracks contains parts routed to one of these plugins as well and had to freeze this track too...by doing so, this would affect other plugins and other and other...no way to go, except for Audiotracks...

With module freezing, MU.LAB had to research, which parts are routed to this module and freeze all of those parts, but minimum render one audiofile per track, to keep clarity...

Part freezing, in my understanding would make sense as mentioned before, if I had parts routed to different plugins on one track...I don't work this way, because for me, it's a matter of clear arrangement, but maybe others (I believe mostly those, who work with MU.LAB free)...???

I believe, those methods are very close...perhaps it's getting clearer, if others get into this brainstorming, with other workflows, other ideas...

To sum this up: I believe, easiest way is to :

1. rightclick a module and choose "Freeze", which affects all parts and automation routed to this module (of course, this function renders audio from only this modules output, e.g. is this a VSTi...from VSTi output, is this a rack...from rackoutput) and automatically

2a. either toogle processing off and treat like an empty Rack

2b. or unload this module to free up RAM and replace with an empty Rack

2c. (better way) optinal both, choosing by an options window

3. autoroute freezed audio to exactly the same position in the complete project routing to not affect further effects routings (is this last one understandable''')

4. Display waveform of freezed audio at the parts position, but partially transparent, so freezed parts are still editable, to be able to make (in this moment not audible) changes to parts and automation for simply refreezing without the need of unfreezing before...

It's quite easy, isn't it???

Lets keep this an open topic where we can collect thoughts and ideas about a freeze system Smile

Are you sure, you shouldn't create a new thread and copy relevant postings to it???

Perhaps, with a better title of the thread, more people come in for brainstorming???

So far
Trancit

[MuTools]

Are you sure, you shouldn't create a new thread and copy relevant postings to it??? Perhaps, with a better title of the thread, more people come in for brainstorming???

I think the topic title is quite relevant.

Anyway, feel free to change the title to what you think is even better.

I'm confident this topic will get more input, step by step.

[robenestobenz]

I do think track/part level freezing is the most intuitive approach, mainly because at the composition level people tend to think of parts as the fundamental elements.

Buuuuuut then I can't really see how track/part freezing would be possible (at least in every case) in Mulab, given the flexible routing system. Say 3 tracks are routed to the same rack for example, and a user wants to freeze one? Not possible. But it is called a track freeze? So what happens now? A dialogue box tells you it's impossible, or asks you if you want to freeze the group because it's not possible in this case? Nah. It's better to have a system which behaves as expected in as many situations as possible and after considering it a bit I personally think the module approach is best to provide that in Mulab.

[MuTools]

On topic: I also tend to think about module-oriented freezing.

With module freezing, MU.LAB had to research, which parts are routed to this module and freeze all of those parts, but minimum render one audiofile per track, to keep clarity.

Not only all tracks/parts targetting that plugin, but also take into account any plugins that are upstream the plugin-being-frozen and thus also all tracks/parts targetting those upstream plugins!

Ok, thinking loud:

Now imagine we have such freeze function, e.g. right-click module -> "Freeze".

Then MU.LAB will take everything relevant into account and generate an audio file with the result. Then on playback the frozen module does not do any processing, instead the frozen audio in the audio file is used to generate the output of that plugin.

Then should the upstream plugs be processed?

If they are only targetting the frozen plugin, then no.
But if they're also targetting other plugs besides the frozen plug, then yes.
I guess. Mmm, not a simple topic.