Why is adding/removing plugins/lanes/effects so slow?

[SenPi]

As far as I'm concerned, I have a fairly good computer, which is making me really unsure as to why it takes 7+ seconds to add a new audio/midi track, or 17+ seconds to add a new effect or delete an effect from my project.

Granted, when it's a new project with nothing in it, everything is quick and snappy, but I just don't understand why adding an effect causes 17+ seconds of waiting.

Here is a video showing how long it takes for me to add things: https://www.youtube.com/watch?v=RwaDpyV-Y5A

Relevant Specs:
- Ableton Live 12 Suite: 12.0.25
- OS: Windows 10 Home: 22H2 19045.4894
- CPU: AMD Ryzen 9 5900X 12-Core Processor 3.70 GHz
- Motherboard: Asus ROG STRIX B550-F GAMING ATX AM4
- Ram: G.Skill Ripjaws V 64 GB (2 x 32GB) DDR4-3600 CL18
- Audio Interface: Focusrite Scarlett 4i4 (Running at 48khz with 256 buffer size)
- GPU: MSI VENTUS 3X PLUS OC GeForce RTX 3080 12GB LHR
- Drives: Samsung 980 PRO 1TB M.@-2280 PCIe 4.0 x4 NVME (My OS and all audio related files exist on here), WD Black SN770 2TB M.2-2280 PCIe 4.0 X4 NVME (This is just for backup/extra data)
- Power Supply: Corsair RM850x 850 W 80+ Gold Certified

I have tried my best to find any and all hints online and in the Ableton manual about making your computer better/faster for audio work, but alas none of them really seem to help all that much.

The project shown in the video has maybe 70+ish lanes (including busses). Is this just too much for ableton? is it my computer? am I doing something seriously wrong?

Worth noting that playing the song is fine. No clicks/pops/dropouts/etc.

This is starting to get increasingly frustrating as my projects get bigger. Please tell me there is something I can do.

Thanks!

[scg]

I don't have an answer, but I can at least offer some corroboration - on my 2023 Mac mini, operations like adding new tracks, moving tracks, etc. can sometimes take a few seconds as well. However, I'm not sure I've seen times quite as long as what you're seeing. But even a few seconds here and there can add up and become a workflow issue, so I do wonder what exactly Ableton is doing internally during those intervals.

[SenPi]

I made the same post on Reddit, and one user gave this interesting comment.

Freezing tracks helps with cpu usage but not stuff like loading tracks and deleting plugins etc. some guy did a big test and posted results on here. The problem is how ableton keeps track of all of the routing. It essentially indexes it in a spread sheet and every time you add or delete something it reconfirms the whole data set. So the more “stuff” you add the slower it gets no matter what. It’s the only daw that works like this that I’m aware of and it’s honestly Ass. Freezing doesn’t help because if you unfreeze it still needs to know the routing so it still has to confirm where all of that stuff is in the index.

The best way to avoid this is unfortunately to use racks and groups only when necessary. I used to use the indiscriminately and now I don’t and my projects are much faster. Drum racks are the worst offender.

I have done a bit of testing, and when I add a new track and get the huge delay, I can see in my task manager that one single core is revving up quite a bit, and then goes back down once the track is added. So ableton has one core doing some serious work adding that track for some reason.

[Cypeace]

Imho it has something to do with iterating trough the array of tracks, recalculating positions of any trailing tracks for input/output, indexing or other stuff in this regard. On empty set it's easy, but the more there is to iterate over, the more cycles it takes to compute.
When I had a very long (as in time) session, panning and other UI interaction was sluggish and laggy.

[scg]

Thanks for sharing that [edit: the Reddit post] - that's interesting information. (Although perhaps not particularly encouraging.)

[x3000]

We had this topic in a thread before and someone noted that racks in particular cause large delays in the GUI. The more, the worse.

[SenPi]

Yeah just as an anecdote of some testing me and some others have done. On one of my very slow projects I opted to move a bunch of groups into busses instead and removed any racks that weren't doing anything other than containing some plugins for collapsing purposes. Definitely gained a bit of speed on adding/removing plugins/lanes.

Kind of weird that busses are somehow faster to compute? I would imagine that groups would essentially just be implemented as busses with a slightly fancier UI, but maybe thats not the case?

Heres some excerpts from another producer doing some tests:

I put 10 channels in a group, duplicated 10 times, then grouped that and duplicated. it took ages for that final dupe

then i made 10 channels, set their output to a bus channel. then I made another bus channel and called it meta bus. then I duplicated the first 10+bus x10. so we got 10x 10 bussed channels fed into the meta bus. then I duplicated everything including the meta bus. it was pretty quick.

I put a utility in a rack (one chain) and duplicated the channel so I had 200 channels. then I selected all channels and duplicated. it took ages.

etc. Supposedly duplicating groups while collapsed is faster than uncollapsed groups too.

[H20nly]

wow

Lines right up with my experience. Any closer would phase cancel