I am Using Mulab 9 (latest version) on my very average laptop, Win 11,and am really struggling with performance issues, it's constantly glitching and red lining the CPU, I run Reaper, FL Studio, and Waveform with MUCH better performance, Is this a known issue with Mulab? or am I really missing some setting that makes the app better?
And is the latest version of Mulab (v10) more efficient in this regard?
Cheers for any help/advice/bad news you can all give.
Cheers, D.
Having CPU issues!!!
-
- KVRist
- 364 posts since 13 Nov, 2010
-
- KVRist
- Topic Starter
- 364 posts since 13 Nov, 2010
Tu give more context, i'm using about 6-7 tracks with a scaler 3 instance, A few Serum 2 Synths, and TAL-DRUM with some saturation processing and a bit of side chain processing into some basic mux ducking setups.
Is there something wrong with my use here?
Is there something wrong with my use here?
-
- KVRAF
- 13862 posts since 24 Jun, 2008 from Europe
-
- KVRist
- Topic Starter
- 364 posts since 13 Nov, 2010
I went through and changed what I could, but there is still a massive difference in under performance compared to my other DAW apps, is there any plans for optimization in upcoming releases? It seems like it could use some love in this area, SUCH a good DAW I really hope it has room for optimization.
Thanks for the reply, it at least helped me understand the basics of how this DAW works.
Cheers, D.
-
- KVRAF
- 13862 posts since 24 Jun, 2008 from Europe
-
- KVRist
- Topic Starter
- 364 posts since 13 Nov, 2010
From a Brave search summary...
"Serum 2 does not utilize multi-threading effectively for individual instances, as it is primarily limited to using a single core or hardware thread per instance, which can lead to high CPU usage on that core even when multiple cores are available. This limitation has been noted by users and developers alike, with reports indicating that Serum 2 may max out a single core easily, especially with complex patches. While some DAWs may distribute different plugin instances across multiple cores, the performance of a single Serum 2 instance does not benefit from parallel processing across multiple CPU cores."
Serum 2 is one core, It seems that the "distribution" of load on DAW's tracks across cores is key to performance...
"Some DAWs, such as Cubase, Reaper, Ableton Live, and FL Studio, are known for efficiently spreading plugin loads across cores on a per-channel basis. However, plugins on the same audio chain (e.g., in series on one track) typically run on the same thread, limiting parallelization due to real-time signal dependency."
As Reaper and FL Studio are a couple of DAWs' I have referenced in comparison I thought this was interesting.
But, I'm no dev, really haven't a clue about this stuff, just hoping a little bumbling amateur legwork may help inspire some better solutions for those much more knowledgeable than myself (you!).
Hope it's helpful and not annoyingly naive...
Cheers for the look in... D.
"Serum 2 does not utilize multi-threading effectively for individual instances, as it is primarily limited to using a single core or hardware thread per instance, which can lead to high CPU usage on that core even when multiple cores are available. This limitation has been noted by users and developers alike, with reports indicating that Serum 2 may max out a single core easily, especially with complex patches. While some DAWs may distribute different plugin instances across multiple cores, the performance of a single Serum 2 instance does not benefit from parallel processing across multiple CPU cores."
Serum 2 is one core, It seems that the "distribution" of load on DAW's tracks across cores is key to performance...
"Some DAWs, such as Cubase, Reaper, Ableton Live, and FL Studio, are known for efficiently spreading plugin loads across cores on a per-channel basis. However, plugins on the same audio chain (e.g., in series on one track) typically run on the same thread, limiting parallelization due to real-time signal dependency."
As Reaper and FL Studio are a couple of DAWs' I have referenced in comparison I thought this was interesting.
But, I'm no dev, really haven't a clue about this stuff, just hoping a little bumbling amateur legwork may help inspire some better solutions for those much more knowledgeable than myself (you!).
Hope it's helpful and not annoyingly naive...
Cheers for the look in... D.
-
- KVRist
- Topic Starter
- 364 posts since 13 Nov, 2010
Maybe it's the side chaining between tracks/racks into Mux patches for ducking and gating between channels? Maybe that joins separate tracks onto the same CPU core?
Seems like inter track signal flow spikes the cpu pretty bad?
Hope it helps.
Seems like inter track signal flow spikes the cpu pretty bad?
Hope it helps.
-
- KVRAF
- 13862 posts since 24 Jun, 2008 from Europe
MuLab indeed does spread parallel processing over multiple cores.
If a module's (eg. plugin) input (any input) depends on the processing of another module's output then these 2 modules cannot be processed in parallel, obviously. Cfr your quote from that other source. So MuLab does all that in that same expected way.
I don't know where your impression of "massive difference" comes from.
It would be helpful if you would rationalize that using the exact same audio setup and exact same test project in DAW X and MuLab.
The only thing on the wishlist wrt the audio engine is to add an option to use an alternative method how multi-threading is done, which may be more friendly towards plugins that use multi-threading themselves.
But that's not relevant to the case here as you mentioned.
If a module's (eg. plugin) input (any input) depends on the processing of another module's output then these 2 modules cannot be processed in parallel, obviously. Cfr your quote from that other source. So MuLab does all that in that same expected way.
I don't know where your impression of "massive difference" comes from.
It would be helpful if you would rationalize that using the exact same audio setup and exact same test project in DAW X and MuLab.
The only thing on the wishlist wrt the audio engine is to add an option to use an alternative method how multi-threading is done, which may be more friendly towards plugins that use multi-threading themselves.
But that's not relevant to the case here as you mentioned.
-
- KVRist
- Topic Starter
- 364 posts since 13 Nov, 2010
So I'm gathering that side chaining would be best setup between sum busses that don't have vsti's on them, a
To minimize pushing single core plugins together?
So side chaining is NOT my friend and probably better to render down than leave processing together?
I'll see if I can demonstrate an apples to apples comparison to demonstrate my experience (or maybe I'm just more likely to do patching that pushes the track into joint cores?). I will try find the time if possible and see.
Again, thanks for the feedback, appreciated a lot.
Cheers, D.
To minimize pushing single core plugins together?
So side chaining is NOT my friend and probably better to render down than leave processing together?
I'll see if I can demonstrate an apples to apples comparison to demonstrate my experience (or maybe I'm just more likely to do patching that pushes the track into joint cores?). I will try find the time if possible and see.
Again, thanks for the feedback, appreciated a lot.
Cheers, D.
-
- KVRAF
- 13862 posts since 24 Jun, 2008 from Europe
If your sound/music project needs side chaining then side chaining is your friend. It's just that if module A is side chained into module B, then module B cannot be processed before module A has ended processing.