Mulab 8 has allergy to VPS Avenger

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Interesting. So it might have to do with multi-threading?

And what plugin did you use?

Post

The plug-in is MeldaProduction MSoundFactory.

When it comes to multithreading, the DAW is in charge of threading in such a way to keep the audio as most in syncronous as possible. Bitwig is straight forward about it, namely that each track is a thread. However, Mulabs modular architecture (even more modular than Bitwig) obscures that. Maybe Mutools can share some light on how they do multithreading.

At any rate, I've never personally had poor experiences with VSTs in Mulab. Everytime I overload the CPU in Mulab, would be a situation that I'd overload the CPU in Bitwig as well.
My Setup.
Now goes by Eurydice(Izzy) - she/her :hug:

Post

Ah ok, never heard of that plugin :)

Post

e-crooner wrote: Sat Oct 26, 2019 8:50 pm
mutools wrote: Sat Oct 26, 2019 11:41 am e-crooner as has been said multiple times already reaper uses pre-rendering. You cannot compare test results of pre-rendered processing with pure realtime processing.
I am not so sure it is the pre-rendering at all.
When I play live, i.e. keep a fat chord pressed without recording and playing back anything, the load is also clearly higher in Mulab.

Here the same Repro-5 pad, 5 continuous notes in HQ mode, with MC support on (without Repro-5's MC support, Mulab is in serious trouble, so there is no point), on the left Mulab, on the right Reaper:

https://app.box.com/s/t2pdp21kyqmfl2mtvg58xern9g1rp7sr

I have no idea where that huge difference comes from...
I found out something interesting: When I do the same test with Repro-5 in ancient Mulab 4.5.2, I get basically the same CPU loads as in Reaper, here is the updated comparison, Mulab 8, Reaper, Mulab 4.5.2 from left to right.

https://app.box.com/s/gzs1h364vxjweqg5fq8h4twocgci92ag

I hope this info helps. Maybe it would be worth trying Avenger in that legacy version of Mulab, maybe he will notice the same difference...


PS: Inspired by that, I tried the current version of Mulab and set the number of threads to 1 (which is analogous to the old version of Mulab, which did not support multi-threading, yet). I added the Mulab 8 1-thread result column at the right, so the order is now:
Mulab 8 multi-core, Reaper, Mulab 4.5.2, Mulab 8 single-thread.

https://app.box.com/s/k72c7idalhobk7rs4flsvv5q5hczi9lz

Seems the problem is the multi-core support in Mulab...

Post

Once again it makes sense that it's that way e-crooner. It takes more power (thus larger graphs in task manager) to compute all signals by the deadline (multi-core of course needing approx. n-threads + master thread times as much power). Measuring DAW performance via the Task Manager is very poor. There's whole technical discussions here on the KVR Forum about it.

Another issue to note: multi-threading audio really only benefits from real cores, not logical threads. So make sure if you have hyper-threading or SMT on your machine, that Mulab is only using half of the available logical threads (a.k.a only using real cores). Otherwise it'll essentially be waiting for two threads to finish calculating by the deadline per-line of audio (SMT/HT are not true parallel processing, they simply share core resources, specifically cache) which means it's taking twice as long (and a little due to a master thread needing to concatenate/sum all signals) to calculate by deadline. That's not perfectly true as there are nuances with cache mechanisms etc, but I hope the general idea makes sense.

Also note that threads are not cores. Threads are an OS level concept and cores are a hardware concept. You can in theory have an infinite amount of threads (not practically, but in theory) on a single core CPU. They're just scheduled tasks that the OS determines when to run. Threads don't guarantee better performance. In fact, when using more threads than cores, it often lessens performance as the CPU has to switch tasks (and thus rebuild cache, etc..).

Again, I'm not being scientific about my explanation, but it's here to give a rough idea on how it works. If you want a real way to test DAW performance, run an instance benchmark (same preset, same audio settings, same IO, same project settings) of a VST and watch the DAW's meter and listen for overloads. Also, don't confuse distortion for overloads. Overloads cause distortion, but distortion is not an indicator of an overload. It's a one way implication.
My Setup.
Now goes by Eurydice(Izzy) - she/her :hug:

Post

I am aware of that. In Mulab I have to enter 4 in the audio setup box where it asks for the number of threads. Initially I had entered 8 (because I have 4 cores x 2 threads), but it didn't work at all. Obviously what is meant is not the number of threads, but cores.

The Windows resource manager diagrams may not be perfect, but they work the way they do for all DAW's. So, they should yield very similar results for identical test scenarios. Don't you think?

Post

Not not at all. Once again, this goes back to architecture. Different DAW's have different methods of accomplishing multi-threading. For example, it's very easy to peg one core to 100% in Bitwig by repeating effects in it's chain. However, Mulab threads effects that are in series in a MUX container. So it's the same chain, but threaded differently. Bitwig keeps all effects on that chain in one thread whereas Mulab will distribute them.

Different DAW's will behave differently. That's why there are different DAW's. Some behaviors are desired over others, and you're just going to have to prioritize them. That's why I (like many other on this forum, including yourself) have more than one DAW. I have more than one workflow and I have different priorities in those workflows. I also understand that different workflows require different power.

It's also very common for users of powerful software (especially modular junkies like me) to purchase powerful hardware to run the software. I couldn't use oversampling in real-time for a while because my older machines simply couldn't handle it. So I saved up for a couple of years and purchased a new machine that could handle my desired tasks. I'm not saying you need to buy a new computer or you're not going to be able to do what you want. What I am saying, is understand that sometimes what you want is not as simple as it seems.

When I was a new Mutools user (7 years back, I was not yet and adult) I made an FR about audio-rate modulation (I didn't have a clue what it was, did, or how it functioned). Years later it's now a staple of the MUX, but I was curious as to why it would be hard to add in. Turns out (after reading about DSP and programming DSP), real-time audio rate modulation is a real sucker to program if you don't want to overload the cpu or make huge latency issues. Not to mention, high quality audio rate modulation needs oversampling to avoid aliasing/quantization errors, which means running the sampling rate for that process at a multiple of the samplerate.

Or take time stretching as an example. There's general theory on how to do it (granular, FFT, convolution, etc...) but each implementation is different. Elastique is different from Mutools is different from IRCAM, etc..

So no, I would not expect two software to behave the same. Otherwise, there'd be no point in choosing. Choosing between red and red makes no sense. Choosing between red and blue on the other hand, is a choice that makes sense. And, in this metaphor, I'll choose the color that best suites my needs for the situation.

Anyway, apologies for the long posts again. I think i tend to get too involved in technical discussion where I shouldn't. I should make more music instead of blabbering about the things I use to make music.

Cheers!
Dakkra
My Setup.
Now goes by Eurydice(Izzy) - she/her :hug:

Post

Sorry for the late reply.

I am not even talking about effects chains and complex stuff, but a single instance of a synth, which can already cause problems.
Ideally plugins have their own multi-core support which seems to work way better than Mulab's. I mean, the DAW itself is very humble, it is the plugins that cause the problem. I can easily run the DAW in one thread as long as the plugins are distributed across all threads by the plugins themselves.

Yes, I do use two DAW's, but not voluntarily, I would love to use only a single one.

Post

mutools wrote: Fri Oct 25, 2019 4:51 am
Khr128 wrote: Fri Oct 25, 2019 1:16 am If it wants to stay in this niche, it's OK, but then do not ask people what stops them from making it their primary DAW.
Which niche?
You keep asking for a technically precise definition of a problem, and as a former scientist and engineer I understand your position, but consider this from the user's point of view. A user is accustomed to running many third-party plugins in their DAWs. Of course, there is a limit to what they can do, and they feel where that limit is. Then they come to Mulab and they feel (not calculate, or measure, feel), that this limit comes much, much sooner than in other DAWs. And even if they feel that Mulab is so much better than those DAWs, this particular issue is troublesome.

So the niche is that Mulab is not playing as well as other DAWs with the huge world of third party plugins. The solution to this problem is difficult to find, because of the incredible complexity of interactions between issues in Mulab (there gotta be some) and issues in the myriad of third-party plugins. I understand that, but it is still a problem for me.

Maybe just finding a trial/free version of plugins that cause problems and starting working with them could show a way to a solution. Or we can stay in the niche of Mulab's own plugins which are completely under control of the developers.

Both outcomes are fine with me. I love Mulab.

Post

Khr128 wrote: Tue Nov 05, 2019 3:44 amA user is accustomed to running many third-party plugins in their DAWs.
I am accustomed to running hundreds of plugins in MuLab and I find it stable. Some plugins have their own CPU meter and measure the same % as MuLab. However, plugin code varies hugely, and interactions among plugins, DAW, MacOS, CPU, GPU, peripherals, drivers, etc in my own systems are so complex I have to be knowledgeable in all those areas, while trying to stay "in the flowww."
Not an easy task.
d o n 't
w a n t
m o r e

Post

Khr128 wrote: Then they come to Mulab and they feel (not calculate, or measure, feel), that this limit comes much, much sooner than in other DAWs.
Who are "they" ?
Then i can tell them: Measuring is knowing.

This thread now is 5 pages long and the only relevant numeric values i've seen tell that there is no problem. I'm open to investigate any issue in MuLab but until now i've soon no prove that there is an issue. (@e-crooner: I again repeat that the Windows task manager is not a relevant measurment tool. Dakkra has explained that well)

One important note which i also already mentioned: MuLab's multicore strategy is not compatible with plugins doing multicore themselves. In the average music project with several/many parallel tracks/racks that's not an issue because if a plug would take advantage of multicore itself it is taking away cpu from other plugins in that project and hence the user gains nothing. So when testing MuLab's VST processing efficiency do not use multicore inside the VST.

I am open towards rational scientific numbers that would prove that there is an issue with MuLab's VST processing efficiency. Please use a test case that can be easily repeated by other users on their system. That's why i recommend using freeware VSTs. I disrecommend installers because they're not transparant, i recommend plugins that come in a zip file. (imho all software should come as zips) And do not use multicore inside the plugin.

Post

What you people ignore is that it is not only about CPU metering. Even if I did not use any such meter, I can hear the difference because Mulab's limit of what it can handle is lower than for instance Reaper's (and no, it does not have to do with pre-rendering as it also happens when playing live). And from what someone else said, Mixcraft also seems to handle more.

Nor can I confirm that plugins' own multi-core support is not compatible with Mulab's. When I turn off Repro's for instance, Mulab can hardly take a single instance when playing fat chords. When I turn it on, things clearly improve.

I continue to consider your rules and conditions for comparisons odd, arbitrary, and unrealistic, to put it mildly.
Which commercial VST plugins are you testing Mulab with if I may ask?

Post

e-crooner wrote: Nor can I confirm that plugins' own multi-core support is not compatible with Mulab's. When I turn off Repro's for instance, Mulab can hardly take a single instance when playing fat chords. When I turn it on, things clearly improve.
You still don't understand. Of course that makes a difference if you're testing a single plugin. But in a realistic project there are many parallel racks and plugins and in that case a VST doing multicore inside will steal cpu from other plugins and you gain nothing. (i'm repeating myself, again)
I continue to consider your rules and conditions for comparisons odd, arbitrary, and unrealistic, to put it mildly.
That's your personal statement. I disagree with it.

Post

mutools wrote: Tue Nov 05, 2019 5:33 pm
e-crooner wrote: Nor can I confirm that plugins' own multi-core support is not compatible with Mulab's. When I turn off Repro's for instance, Mulab can hardly take a single instance when playing fat chords. When I turn it on, things clearly improve.
You still don't understand. Of course that makes a difference if you're testing a single plugin. But in a realistic project there are many parallel racks and plugins and in that case a VST doing multicore inside will steal cpu from other plugins and you gain nothing. (i'm repeating myself, again)


I continue to consider your rules and conditions for comparisons odd, arbitrary, and unrealistic, to put it mildly.
That's your personal statement. I disagree with it.
There is nothing unrealistic about using an instance of Repro or Lush in a project. When one instance already pushes Mulab to the limit, there is nothing left for other plugins to share with.

For me personally it is only a theoretical discussion because I use only highly optimized plugins that my computer hardly registers. But I am not the rule, many people like to use those modern synths from U-he and the like.
Still it is an important discussion because it might indicate that there is a problem. And others in this thread have made the same observations.
I don't know Avenger, but I remember it was the same with some Dune patches.

Post

I use plenty of vst's in mulab - in One-Synth-Challenge we have a different synth every month. Remarkably few vsts have had any issues running in mulab, and they seem to integrate very well. Coming from Cubase Pro, and also having tried bitwig 8-track, Tracktion and Waveform free, and Ableton Lite, I cannot say I have noticed any real difference in cpu performance to date. I always let mulab handle the multi-processor processing and turn it off in any multi-processor capable plugins, this is good advice for other DAW's too. Mulab seems to spread the load pretty evenly across cores for me.

MsoundFactory, Dune3, Thorn, Padshop pro, Hive2, Synthmaster One and 2, to name a few, all work great with mulab! Might be interesting to try a proper comparison when I have the time - but its kind of searching for a problem I don't actually have.

The real advantages of using mulab in my opinion are its very powerful modular system, ease of use and light footprint.

Post Reply

Return to “MUTOOLS”