GUI Responsiveness Issues while Handling Lots of Multitrack Edits

Hey folks,

as a band we’ve made drum recordings (8 tracks, 7x mono, 1x stereo) and I’ve edited them with ardour. Unfortunately, there are lots of cuts and small edits, hence we end up with lots of regions. My current problem is, that the number of regions makes that ardour project instance painfully slow to work with. I can barely select the regions to combine or freeze them.

I did the editing on my own but in a couple of weeks I want to fine tune stuff with my band mates - having a extremly laggy ardour project does not work. By “extremly laggy” I mean that (rectangle-drag-)selecting regions takes ~20s, same for trimming, moving etc. Right-click context menus pop up after 20s (if at all), zooming is a pain too etc. CPU remains on ~16%.

Suggestions are welcome :slight_smile: Freezing or combing does (even if I wait for the dialogs to pop-up) not really finish (I went inpatient after 10minutes).

Some specs:

  • Ardour 8.2.0 built from github
  • running on Ubuntu 20.04 LTS with Ubuntu Studio
  • CPU is an Intel i7-7700k

(The other tracks like Guitars and Vocals are currently unedited, even without the project does not speed up, hence I blame the drum regions).


PS: I’m aware of 0002982: performance issue with lots of regions (bad scalability) - MantisBT - seems like the issue is around for quite a while.

Export Drumtracks stemps and reimport in DAW!?

Ardour 5 was terrible for this issue but since 6 I haven’t noticed it so much. I do many projects with 100s of regions with no issue. Recently I did one with about 4000 regions and I did get a bit of lag there. In my projects it’s pretty much impossible to open the region list without Ardour freezing :slight_smile:

I’m on a newer CPU with more threads and have a lot of RAM so perhaps that is significant. I also wonder if there is anything we can do to optimize sessions with lots of regions.

Is this an optimized build?

In Menu > Help > About . Config. is there Debuggable build: False?


@x42 in deed, seems like I’ve made a debuggable build. I’ll try to rebuild an optimized build! :slight_smile:

/EDIT: Worked! The problem is gone by rebuilding without debug stuff.
To link my actual solution here (so people can find it via google): I’ve made my optimized build with:

./waf configure --optimize
./waf i18n

(i18n because of the German GUI, not related to the issue but turned out to be useful for me too).

@guth: Sure, but I’d lose the ability to fine-tune the editing, because the original recording’s data are (obviously) cut.


Ardor is non-destructive, each individual region contains the complete original trace. Sorry but I thought they were finished editing :wink:

Hey folks,

are there more options to optimize by ardour build in terms of GUI performance?
Meanwhile I am running an optimized build of v8.2.0 and I’m working on another
editing session (fresh recordings, 12 tracks, lots and lots of cuts): slicing tracks
takes more and more time the longer I edit in this project.

Any help’s appreciated ^^