View Issue Details

IDProjectCategoryView StatusLast Update
0006518ardourbugspublic2020-08-23 08:22
Reporterunfa Assigned To 
Status confirmedResolutionfixed 
Fixed in Version4.X git (version in description) 
Summary0006518: Undo goes way back and works unpredictably. Ardour 4.2
DescriptionI've got a big session with tens of tracks, as I'm mixing audio for a 1.5 h long documentary film. I'm cutting input 3 tracks exported from Adobe Premiere into separate persons, situations and layers.

Ardour seems to have better and worse hours for this issue - sometimes a few times in a row when I press Ctrl+Z Ardour undos not the action I've just did, but something else I did minutes ago. The indication is that view of the session changes, the scrolling jumps, sometimes I can immediately see what was undone (it's becoming selected), sometimes I don't. This leaves me fearful, that my session has some random stuff in it that I'm not aware of and I'll need to listen to all of it again to find out (I'll have to do that anyway, but still I wish I saw no surprises there).
Additional InformationI'm using Ardour 4.2 from KX Studio repositories on a Dell Latitude 3550 laptop running KX Studio 14.04 with KDE desktop.
TagsNo tags attached.


related to 0006338 closedtnaugle while dragging / cutting region 
related to 0006527 closedtnaugle Ardour freezes when typing 'S' while dragging a region 



2015-08-19 04:07

developer   ~0017059

I also noticed this. I've pushed a fix(bb790710) for undo/redo when changing the fade out length of a region. Hopefully this was the issue you were experiencing.


2015-08-20 21:21

reporter   ~0017079

Same issue here (Ardour 4.2), I wanted to report it but found this bug report, and it seems to be the same.


2015-08-24 14:27

reporter   ~0017104

Last edited: 2015-08-24 14:28

Same issue (4.2 official, Debian 8).
Is the fix already in the nightly build?


2015-08-24 16:44

administrator   ~0017105

Last edited: 2015-08-24 16:44

bb79071 = 4.2-44-gbb79071 (after 4.2-0) and yes nightly builds are currently 4.2-62 and include this fix.


2015-09-04 13:02

developer   ~0017141

Any further feedback on this issue? have you tried a more recent build to see if this is still a problem?


2015-09-04 21:32

reporter   ~0017142

In nightly it doesn't seem to be a problem any more.


2015-09-05 08:31

developer   ~0017143

Ok, great. Thanks for confirming.


2015-09-08 05:28

developer   ~0017158

I'm reopening this. There is another issue with undo and splitting regions.

If I move a region and then select a range within the region and use the 's' key to split at range boundaries then undo will undo the split but also move the region back to where it was before the move.

This should be easy to fix but I don't have time to look into it right now so I'm leaving this note


2015-09-08 06:05

developer   ~0017162

Just confirming this issue, not assigning it to myself. mantis seems a bit strange sometimes.

2015-09-09 01:16


separate_regions.patch (1,019 bytes)   
diff --git a/gtk2_ardour/ b/gtk2_ardour/
index f0940fe..37d836e 100644
--- a/gtk2_ardour/
+++ b/gtk2_ardour/
@@ -3032,6 +3032,8 @@ Editor::separate_regions_between (const TimeSelection& ts)
 						latest_regionviews.clear ();
+						XMLNode* orig_state = &playlist->get_state();
 						playlist->partition ((framepos_t)((*t).start * speed),
 								(framepos_t)((*t).end * speed), false);
@@ -3048,16 +3050,8 @@ Editor::separate_regions_between (const TimeSelection& ts)
 								in_command = true;
-							/* pick up changes to existing regions */
-							vector<Command*> cmds;
-							playlist->rdiff (cmds);
-							_session->add_commands (cmds);
-							/* pick up changes to the playlist itself (adds/removes)
-							 */
-							_session->add_command(new StatefulDiffCommand (playlist));
+							_session->add_command(new MementoCommand<Playlist>(
+							    *playlist, orig_state, &playlist->get_state()));
separate_regions.patch (1,019 bytes)   


2015-09-09 01:18

developer   ~0017170

I've uploaded a patch that although seems to fix the issue, I don't believe to be correct and it has issues.

This may need to wait until a developer with more experience/time with the undo system can look into it.


2015-09-14 12:48

developer   ~0017192

I've noticed a few other issues so I'm making note of them now before I forget.

Selecting a range and cutting it with ctrl+x and pasting with ctrl+v, then undo/redo is two steps instead of one.

Selecting a range and Cut/Copy and paste and then Undo, pasting again(after undo) causes the region to be offset from the edit point by the width of the range. undo and paste again will offset it again by another range width.


2016-12-28 19:26

reporter   ~0019229

Last edited: 2016-12-28 19:27

This bug seemingly has resurfaced again. I guess, something in my project file makes the undo/redo engine behave abnormally. When I do recording to the track "cl. guitar", sometimes there is no undo of the last action, sometimes it undoes two last actions, oftentimes it even removes the last recording take. This is a very severe problem as it often causes good takes to be destroyed.


2016-12-28 19:29

reporter   ~0019230

Last edited: 2016-12-28 19:30

As the "Upload File" button above does not work (APPLICATION ERROR 0000401 / database error), here is the link to the troublesome project file:


2016-12-29 11:12

reporter   ~0019233

i think the best way to track this down is to get a copy of the session
.history file when it happens.

ideally it would be two copies - you see the bug happen, copy the history file
hit "redo" and copy that history file using a different name.


2020-08-22 23:25

reporter   ~0024950

I'm seeing this issue as well. Specifically it seems like, when hitting 'undo' while the ui is trying to catch up after a recording a take, Ardour will delete the take BEFORE the one just recorded. I've attached a video of this happening in a particularly large session where the track I'm recording on has multiple regions on multiple playlists which really delays the time it takes for Ardour to catch up after recording on that track. In the video, waiting for the playhead to return to the starting point allows 'undo' to work as normal.


2020-08-23 08:22

reporter   ~0024951

Another user here. I've seen many many times Ardour undo not the last recording but the one before. These all happened on Ardour 5.12 (I haven't moved to 6.x yet). I'm glad you managed to track the issue down to session update after recording stops. My sessions also tend to have many hundreds or a few thousand regions and updating might take a while. I tend to press ctrl +z immediately after stopping recording if I decided the take was bad. Maybe Ardour is still doing something at that time and the newly recorded region has not yet registered in the "undo buffer" and a wrong take is deleted.

Issue History

Date Modified Username Field Change
2015-08-18 16:09 unfa New Issue
2015-08-19 04:07 timbyr Note Added: 0017059
2015-08-20 21:21 polosson Note Added: 0017079
2015-08-24 14:27 Boesmann Note Added: 0017104
2015-08-24 14:28 Boesmann Note Edited: 0017104
2015-08-24 16:44 x42 Note Added: 0017105
2015-08-24 16:44 x42 Note Edited: 0017105
2015-09-04 13:02 timbyr Note Added: 0017141
2015-09-04 20:10 x42 Status new => feedback
2015-09-04 21:32 unfa Note Added: 0017142
2015-09-05 08:31 timbyr Note Added: 0017143
2015-09-05 08:31 timbyr Status feedback => resolved
2015-09-05 08:31 timbyr Fixed in Version => 4.X git (version in description)
2015-09-05 08:31 timbyr Resolution open => fixed
2015-09-05 08:31 timbyr Assigned To => timbyr
2015-09-08 05:28 timbyr Note Added: 0017158
2015-09-08 05:28 timbyr Status resolved => assigned
2015-09-08 06:03 timbyr Assigned To timbyr =>
2015-09-08 06:05 timbyr Note Added: 0017162
2015-09-08 06:05 timbyr Status assigned => confirmed
2015-09-08 09:08 x42 Relationship added related to 0006338
2015-09-08 09:08 x42 Relationship added related to 0006527
2015-09-09 01:16 timbyr File Added: separate_regions.patch
2015-09-09 01:18 timbyr Note Added: 0017170
2015-09-14 12:48 timbyr Note Added: 0017192
2016-12-28 19:26 efenstor Note Added: 0019229
2016-12-28 19:27 efenstor Note Edited: 0019229
2016-12-28 19:29 efenstor Note Added: 0019230
2016-12-28 19:30 efenstor Note Edited: 0019230
2016-12-28 19:30 efenstor Note Edited: 0019230
2016-12-29 11:12 nick_m Note Added: 0019233
2020-08-22 23:25 valiantBlunder Note Added: 0024950
2020-08-23 08:22 mhartzel Note Added: 0024951