MuLab & MUX Vst 5.5.2

[mutools]

MuLab & MUX Vst 5.5.2 are available as a patch in

http://www.mutools.com/mulab/app-patch/

What's changed since M5.5.1:

• When using mono legato the filters are now also properly applying key tracking.
• The Multi-point Envelope velocity sensitivity was not working correctly. Fixed.

M5.5.2 comes as a binary app patch.
For installation instructions see http://www.mutools.com/mulab/app-patch/Read%20Me.txt
Basically it's about updating the app/exe/dll and ID files.

Cheers!

[fluffy_little_something]

Used Mulab again after a while, and updated to the latest version. Have you changed something about the mixdown? In the past (months, maybe half a year ago) when I mixed down @ 32bit, the result was full of clicks and other irritating noises rendering it useless. Now it works flawlessly

By the way, what has a bigger impact on the sound quality, bit depth or sampling rate? I have set everything to 16bit and 96kHz, I hear no difference to 24bit, frankly. Maybe my ears suck
But I think I do hear a slight improvement using the higher sampling rate, especially with some synths on higher octaves.

I never really understood which audio settings matter for the mixdown. In Windows there are sampling rate and bit depth settings, in the ASIO driver there are also sampling rate and bit depth settings, in Mulab there are audio settings, and for the mixdown there is at least the bit depth setting. Which ones actually impact the sound quality of the final mixdown and which only impact monitoring so to speak?

[mutools]

Used Mulab again after a while, and updated to the latest version. Have you changed something about the mixdown? In the past (months, maybe half a year ago) when I mixed down @ 32bit, the result was full of clicks and other irritating noises rendering it useless. Now it works flawlessly

Indeed there was a fix in the mixdown engine when using VSTs on a multicore machine, which is a regular case of course. The fix was in M5.3.25 cfr the changelog on http://mutools.com/mulab-mux-change-log.html

By the way, what has a bigger impact on the sound quality, bit depth or sampling rate? I have set everything to 16bit and 96kHz, I hear no difference to 24bit, frankly. Maybe my ears suck
But I think I do hear a slight improvement using the higher sampling rate, especially with some synths on higher octaves.

This is a non MuLab specific question so maybe better to ask it in a generic sound engineering/production forum. As a draft answer i would say they're both important but wrt mixdown i think samplerate maybe a bit more important than bit depth because the 16 bit limit is only applied at the very last step and so it only affects the final values. Anyway, i'll leave it to others to pick in.

I never really understood which audio settings matter for the mixdown. In Windows there are sampling rate and bit depth settings, in the ASIO driver there are also sampling rate and bit depth settings, in Mulab there are audio settings, and for the mixdown there is at least the bit depth setting. Which ones actually impact the sound quality of the final mixdown and which only impact monitoring so to speak?

The mixdown settings affect the mixdown, the Windows and Mu Audio Setup settings affect what you hear = your monitoring. Note that in MuLab the mixdown samplerate is always the same as the one you chose in your audio setup. So the only option that is 'dual' is bit depth. You need to have the mixdown bit depth option because it depends on what you want to do with the resulting audio file. For example some (older) apps don't support 32 bit audio files. Or you may want to have a smaller audio file size.

[fluffy_little_something]

Cool. That means that when I use lower audio settings for working/monitoring (for instance because my computer is not the fastest and can't take 16bit-96kHz with certain plugins) and it sounds like crap live, it does not matter as long as I mixdown using higher settings, right?

The only exception might be audio recordings like vocals. I mean, when I record them at low settings, the resulting loss of audio quality can't simply be compensated later on during mixdown.

[mutools]

Cool. That means that when I use lower audio settings for working/monitoring (for instance because my computer is not the fastest and can't take 16bit-96kHz with certain plugins) and it sounds like crap live, it does not matter as long as I mixdown using higher settings, right?

Samplerate is equal for reallife and mixdown, but you could set it to a lower setting for reallife and when the track is ready then set samplerate to a higher setting for a final mixdown.

Changing the bit depth won't affect the cpu usage though for the internal audio engine always uses 32 bit floats. (this might change to 64 bit floats in a future version)

The only exception might be audio recordings like vocals. I mean, when I record them at low settings, the resulting loss of audio quality can't simply be compensated later on during mixdown.

Correct.

[fluffy_little_something]

Is there a way to increase the size of fonts, like in the browser? It is all so tiny
I found the setting for the menues, have set them to 24, that is nice

By the way, what I always wondered, why that default patch when opening Mulab? It is an odd sound, I wonder if anyone ever uses it...

[mutools]

Is there a way to increase the size of fonts, like in the browser? It is all so tiny I found the setting for the menues, have set them to 24, that is nice

Not yet in M6.0 but it's in the pipeline. Maybe in M6.x

By the way, what I always wondered, why that default patch when opening Mulab? It is an odd sound, I wonder if anyone ever uses it...

Whether you like a sound or not is a subjective matter. Luckily you can easily change the "New" session template and set it up as you want. How to:

* Change that sound to something you like
* SESSION menu -> Save As Template
* Enter "New"

From now on doing "New" will use your favorite sound

[fluffy_little_something]

Yes, I know about the template thingy, never bothered using it so far, though.
I was just wondering why you chose that sound. I think for those demoing Mulab something like Notes in Space might be more appealing as the first sound they hear Mulab make

[fluffy_little_something]

It might make sense to highlight the currently selected patch and/or put it at the top of the drop-down menu of the VST window. Currently when I have a plugin with lots of presets and pick the, say, 114th, the next time I open the drop-down menu I am back at position 1 again and number 114 is not highlighted when scrolling down. If patches don't have numbers it might be difficult to find them again in such a long list.

Funny that one can delete the Master rack. How do I get it back into an existing session?

[mutools]

It might make sense to highlight the currently selected patch and/or put it at the top of the drop-down menu of the VST window. Currently when I have a plugin with lots of presets and pick the, say, 114th, the next time I open the drop-down menu I am back at position 1 again and number 114 is not highlighted when scrolling down. If patches don't have numbers it might be difficult to find them again in such a long list.

Even if the program would be highlighted at the moment the list pops up chance is very small that you will see it because the highlight in that list follows your mouse and so the highlight will be immediately changed.

Funny that one can delete the Master rack. How do I get it back into an existing session?

Note that 'the' master rack is just a normal rack. You're not obliged to use a master rack. You can indeed delete it and work without such rack, or use multiple such grouping racks, it's all very flexible.
How do you get it back? Just create a new rack, name it "Master" and route all other racks to that rack

[fluffy_little_something]

Ah ok, I thought it might be somehow different inside from other track racks
Just tried it, changing the outputs of other racks to the new master seems enough...

Was demoing Sonar X3 days ago, gee, it is nice to use Mulab again, Sonar was overwhelming in every way

[Reincke]

Note that 'the' master rack is just a normal rack. You're not obliged to use a master rack. You can indeed delete it and work without such rack, or use multiple such grouping racks, it's all very flexible.
How do you get it back? Just create a new rack, name it "Master" and route all other racks to that rack

MuLab is so cool...
But it's funny, similar to fluffy I noticed a different behaviour between MASTER-Rack and the others: The list of selectable outputs varies. Why? Does MuLab prevent from defining recursive routings?
JR

[mutools]

Yes, that's the reason. You'll see the same type of contextual option filtering applied when using common send fx racks etc.

[fluffy_little_something]

Because of my SynthEdit stuff I usually only use the 32-bit version. Anyway, I just updated my old 64-bit version (the old one was from March 2013). I discovered some older projects in my folder and ran them. They did open and play, but they sound very different. There is a guitar sound for instance, which sounds as if it were drunk now Totally off somehow. The whole piece sounds rather different.
While I appreciate updates, I wonder if it makes sense to change the sound as such. When will the sound engine or whatever be finished so that older projects will continue to sound the same in future versions?
In this case it does not matter as those old projects were not good anyway, but if they had been important, I would have to sit down and redo the sound programming, the mixing and what not. Not a pleasant task...

Just loaded another project which had lots of Noizemaker patches in it, it still sounds more or less the way it should. Seems the changes in the other projects are mostly limited to Mulab's internal synths and sounds.

[pljones]

Of course, you can always keep the old MuLab to open important old projects that should not change. After all, it's important that they do not change, you do not really need to open them (at all ) in the new version. There were some sound engine changes fairly recently (documented in the change history, as always).

I'd rather we keep getting a better MuLab than change be prevented by compatibility issues, particularly as there's the freedom to keep (and redownload) the old versions.