Ableton Live research how to best utilize CPU cores

[dermage]

So I know, there have been some threads about it, but didn't find any suitable to have a list of practices to make Ableton use all possible cores. I'm seeing this a lot with my projects, that Live renders only on 2 cores during export. Also on some tutorials (even on Ableton's) it's said, that side chain routing makes the audio path more narrow so it's depending on previous signal to render first and in the end use less cores/threads to compute. So I started a test today.
I post it here since I think the Ableton forum is dying anyway.

My setup: Intel quad core i7-2600k with 16gb ram, Focusrite Scarlett solo 2 with 1024 buffer (but 256 buffer is very similar with that test)

8 Tracks of Repro 5 (or I guess possibly any other heavy synth) playing 4 full notes at the same time using the Init Preset in 1 bar loop in HQ mode, but Multicore disabled, so it just uses the Track's single thread.

What I can do without the CPU overloading. Utilizes all cores fully:
- I can put a Compassion (or I guess any other compressor) instance behind them in each track and route a Kick Loop from another track into it to have side chain compression.
- I can group all Repro tracks to one group

What I can't do is:
- Use just one send/return -> instantly overloads CPU (even with no device there)

So I can conclude using Sends is bad for multicore usage in Live? Even as we are told it's better to share effects like reverb to keep processing down. In the end it's worse for me to reduce multicore usage... and seemingly better to have reverb/fx on the channel itself inserted with a Wet/Mix setting.

What are your thoughts? And did you notice something similar?

[generaldiomedes]

I would also try this on a non u-he synth without its own Multicore setting (I always turn that on anyhow) but interesting results.

[dermage]

I would also try this on a non u-he synth without its own Multicore setting (I always turn that on anyhow) but interesting results.

Yes, but I need to know if these synths do not use multiple cores/threads internally. I tried to setup with Diversion or Avenger but could not get a steady high cpu across all cores as with Repro yet. I try not to use more than 8 instances of synths, because my processor only offers 8 threads/virtual cores, so want to more or less be sure that each track gets a core.

Btw.: The core of my research is impact of routing in Ableton Live. So next test would be to see if Midi routing alone is better than Audio routing. (eg. trigger compressor by midi, as possible with Volume Shaper).
But my finding, that Send routing is more intensive than sidechain routing a track already surprised me well.

I find it kind of sad, that the internals of DAW processing are not documented well. Like it is with electronic devices, where there at least (mostly) is a routing graph attached.

[Reefius]

You can also use Ableton Live to make music, it's a very versatile piece of software

[dermage]

You can also use Ableton Live to make music, it's a very versatile piece of software

Actually I'm doing this
But constantly trying to improve its or mine efficiency when working with it. It's a big difference when I actually can use my computer's power to the fullest - faster render, faster workflow without a lot of freezing.

[antic604]

So I can conclude using Sends is bad for multicore usage in Live? Even as we are told it's better to share effects like reverb to keep processing down. In the end it's worse for me to reduce multicore usage... and seemingly better to have reverb/fx on the channel itself inserted with a Wet/Mix setting.

Indeed, I always wondered if that advice to always use Sends to reduce CPU load was really true. You see, for Send track to work, it has to wait until the signal from all tracks that are routed to it is ready and only then can it process it. So what happens, if - for example - 3 tracks are finished but 4th is still processing? Can the CPU cores / threads occupied by first 3 tracks be free to do something else? What if there's no other tracks to process?

Although this doesn't explain your case, because you're using the same instrument & patch on each track.

I'll have to check it when back at home.

[dermage]

Indeed, I always wondered if that advice to always use Sends to reduce CPU load was really true. You see, for Send track to work, it has to wait until the signal from all tracks that are routed to it is ready and only then can it process it. So what happens, if - for example - 3 tracks are finished but 4th is still processing? Can the CPU cores / threads occupied by first 3 tracks be free to do something else? What if there's no other tracks to process?

Although this doesn't explain your case, because you're using the same instrument & patch on each track.

I'll have to check it when back at home.

Interesting thought!
That may be a bottleneck.

But actually it should be same for side chained inserts at the end of my tracks?! Or is the side chain source rendered first?!
Logically side chain sources should behave like Sends, don't they?

[Mathematics]

Developers notes were posted on this exact topic. This was talked about on the Abbey Roads Chambers post in Effects. I went into specifics about this exact issue. What you need are more clock cycles, not better use of cores. You can't make a car go faster by attaching a second car, just like you can't run faster by adding a second person to run with you.

Since the Sends are part of a signal chain and not a second signal chain, you can overload the CPU. You need a faster CPU or you need less effects on the send buss. Everything else you know about grouping to sends is correct.

https://help.ableton.com/hc/en-us/artic ... ndling-FAQ

[generaldiomedes]

So use things like lfotool for ducking and don’t use sends

[carrieres]

thanks Mathematics