View Issue Details

IDProjectCategoryView StatusLast Update
0009547ardourbugspublic2024-03-17 22:10
Reportermhartzel Assigned To 
Status newResolutionopen 
PlatformArchOSLinuxOS Version(any)
Product Version8.1 
Summary0009547: Using "Snapshot and switch to new version" repeatedly becomes veru very slow after some time
DescriptionI routinely use "Snapshot and switch to new version" when composing new music with Ardour. I have been bitten by a corrupted session and lost work a couple of years ago and started to use this feature to save a new version of the session every time I have recorded an idea that I don't want to lose.

Recently I started a new project with Ardour 8.0 and after about 40 times of using "Snapshot and switch to new version" it became very very slow. A normal session "save" however is still very very quick, only "Snapshot and switch to new version" is unbearably slow now. The session is on a SSD - disk which is working fast and flawlessly.

I made a video of me saving the 51st version with "Snapshot and switch to new version" and it took 2 minutes and 4 minutes to complete. The video is here:

Here is the session stripped of all audio:

- Manjaro Linux KDE
- Ardour binary is from your website, I used 8.0 for the first 50 sessions I created and 8.1 for the last one in the video.
- Processor: AMD Ryzen Threadripper 2950X 16-Core Processor, 64 GB Ram.

There are 23 696 midi files in the session and I suspect that might have something to do with the problem. I myself have not made so many midi regions, I suspect they might have been duplicated every time I created a new version of the session.
TagsNo tags attached.



2024-03-17 07:27

reporter   ~0028597

I have now confirmed that Ardour 8 (also version 8.4) makes duplicates of each midi file in the session when using "snapshot and switch to new version". The extra copies makes each new session slower and slower to use.

The expected behavior would be to just make a copy of the session file and not anything else. I can't think of a reason for Ardour making duplicates this way so I assume it is a bug of some sorts.

I have now stopped using "snapshop ..." and instead shut down Ardour and make a copy of the session file myself and the start Ardour again and load the new session file. This keeps my sessions lean and fast.
Here is a video of a newly created 8.4 session with the file manager showing the "midifiles" folder. In the video I first create a simple 2 pattern midi rhythm and then make 100 copies of it to get a drum beat of little over 6 minutes, Then I use "snapshot and switch to new version" and the file manager shows how Ardour each time makes unnecessary duplicates of these 100+ midi files.


2024-03-17 18:24

updater   ~0028598

I replied here:, but clearly the behaviour is not ideal for cases where there are many MIDI files.

The example here is maybe not the best: making 100 identical copies of a MIDI region would probably best be done as linked regions (sharing the same underlying MIDI file) unless there's an intent to modify each one of them individually afterwards, but I can certainly see that there are workflows where large numbers of MIDI files can get created, and clearly the impact of this on the performance of "Snapshot" in this case is not good.

One solution would be some kind of copy-on-write for MIDI regions, where MIDI regions can be flagged to have their underlying MIDI file copied when the region's MIDI is first edited, and for snapshot saving to set this flag on all MIDI regions in the snapshot, but I can see how this could be both complex to implement and potentially confusing to use.


2024-03-17 20:23

reporter   ~0028599

Thanks for the info. The "copy on write" only needs to make a copy of a midi region for the session version currently loaded in Ardour, it does not need to touch any regions that are not modified. This is how file system snapshots works, it is the exactly same principle. Only make a copy of the data that is being modified and don't touch any other data. I can't think of why it would be complicated to use as it would be completely hidden from the user.

Anyway thank you for helping me out.


2024-03-17 22:10

reporter   ~0028600

Just talking random thoughts out loud here: this corner case seems to stem from the fact that midi data is stored externally to the session file. The session has no other way of owning its own copy of midi than making duplicates of the external files.

If however midi data were to embedded inside the session, then the session would own it’s own copy of the data and there would be no risk of overwriting data of other session copies ever.

Or if the all midi data in a session was stored in one file owned by the session then this category of problems would also go away.

Seems this is more about how the data is stored than if midi files are individual or linked.

Issue History

Date Modified Username Field Change
2023-11-22 13:13 mhartzel New Issue
2024-03-17 07:27 mhartzel Note Added: 0028597
2024-03-17 18:24 colinf Note Added: 0028598
2024-03-17 20:23 mhartzel Note Added: 0028599
2024-03-17 22:10 mhartzel Note Added: 0028600