Bugzilla – Bug 1823
Recording interacts badly with Undo
Last modified: 2018-08-20 11:45:29 UTC
Fixed at https://github.com/audacity/audacity/commit/1e8aba968da56374d74fb5589caa56caf5fe1283 Please test thoroughly!
Built with the mentioned commit. Start recording, stereo, Cmd+. creates a blank area ABOVE the recording tracks the size of a label track. Hit spacebar to stop recording. CRASH! Note: This is above the recording tracks and not below as normal.
Noted. Suppose the wave and label tracks already exist and you append-record. Does that work?
I am reverting my fix until I figure out that crash.
Answering your question in comment 3: That works in that it doesn't crash on stopping the record. However the recording display goes off the right hand end of the track and is invisible from then on. Even key strokes CMD+F don't pull the display of the full track into view. On stopping the recording then CMD+F works to display the full recording. The UNDO then works normally. BTW, I did the same tests with 2.2.2 built 10 January and also with 2.2.1 and they all did fine, no crashes and undo works properly all the way back to an empty project.
In 2.2.1, how long did you wait between the undoable actions? I think this problem goes by roughly five-second intervals of recording. So wait that long between dropping labels. Then, do you see the bad behavior?
I'm not sure what you mean by "dropping labels". I recorded for about 30 seconds then moved the pan and gain sliders then at about 40 seconds created the label track then about 10 seconds later typed a letter to add text to the label. Stopped recording a bit later and did undo and it did pretty much in sequence for what I had done all the way back to an empty project. Total track length about 1:20. Did multiple REDOs and everything came back.
Yes, but there is a last undo item for the recording, which, however, does not undo all of the recording. In 2.2.1, 1) Do you see that? 2) Do you agree that's wrong?
Checking History there are no more undos to be done. It does say Total Space used = 27MB, however doing append record in the now empty project starts the space count all over so apparently the data is discarded when the new recording starts. Same events in the new recording are also undone as before so I don't see any issue myself. Do you have a specific series of actions that show the problem on your system?
(In reply to Cliff Scott from comment #9) I say each of the undo steps removes a part of the recording, but that is wrong. The last undo step should remove all of the recording. Do you see what I mean.
I'm sorry Paul, but apparently I'm still not on your wavelength. Guess I'm dense this evening. By last undo do you mean the one that wipes the screen clean so it appears as if Audacity was just started? If so then you are saying that at that point there should be no possibility of redo, correct? When I undo by steps the last undo leaves the Audacity window blank as if Audacity had been just started, however a Redo brings everything back. If you are saying that the last undo should wipe out the possibility of Redo, I would say that is a design question. For me personally I would leave the redo data until Audacity was closed or a new recording was started which it appears to me to be what is happening. I would assume that it is very unlikely someone would completely undo a recording then change their mind and want it back, but who knows what people might want to do. Is there some harm or another issue that is caused by the current behavior?
Rereading your initial email regarding the fixes I FINALLY see that you mean that after a recording one UNDO should wipe the entire recording. Again, I would say that is a design question that hopefully others would chime in on. If the one shot removal of the entire recording was done then would you keep a redo history in case they changed their mind? We already have the "X" in the track panel to remove it in one shot with no redo history so am not sure why this change needs to be done.
(In reply to Cliff Scott from comment #12) Ah, yes, confusion over what I mean by "last". Undo history is a last-in first-out stack. I mean the last undo item pushed -- which appears at the bottom of the list in the History window, and says "Recorded Audio" -- but is also the first item that you undo afterwards. I say that that undo item ought to cover the entire recording, and nothing but the recording. Whereas the other things listed above it -- like moving sliders or adding labels -- should undo only the things that are in their names, and not also undo a part of the recording. (Except some changes in the view -- like track heights and change of selection -- these can combine with any undo item.) And whatever you undo, should be available for redo if you do not make another edit first.
Ahhhh. Ok I see what you mean when using the History to do the UNDO. Even though the recording is highlighted it doesn't undo the whole recording, but just parts and if you work your way up the list you are left with part of the recording that can't be undone. Of course you could use the X in the track panel and that would be the easiest in the first place. The undoing parts is obviously wrong. My understanding is that History should just work with the undo data, not the current state of the recording so it shouldn't change anything on screen which is quite different from cmd-Z. Are you thinking to make the two more similar in their actions? If I understand correctly what you are proposing then it is, in my opinion, contrary to what I understand to be the purpose of the History, i.e. just to reclaim space by removing undo history, but not to change the current recording or editing state. Do I understand you correctly on this? Is my view of the purpose of History correct?
Undo History allows you to make exactly the same changes that repeated Undo and Redo commands can do, by picking one of the rows in the table. Therefore history CAN change the state of the project and what is draw in the screen. History also shows information about space usage. History also allows you to discard the oldest items to reclaim disk space, but then those become unavailable. This bug report does not claim anything is wrong or lacking specifically in the behavior of the History dialog. I mention it only to aid in understanding the wrong behavior that you can demonstrate either by picking a line in the dialog, or by repeated Undo and Redo commands.
As per my email: Testing on macOS 10.13.2 High Sierra with audacity-macos-nightly-2.2.2-4ef8da8.dmg - 26.27 MB | version: 2.2.2--15Jan18 1) Undos work, but the recorded audio is removed a bit at a time in between the undoing of labels pan/gain. With final Undo I am still left with the segment of audio recorded before the first label was dropped. In the user's mind surely the completion of the recording (the whole recording) with these steps should logically be the last thing on the stack - and thus the user could realistically expect the first Undo to delete the recorded audio. In fact if all I do is Record and then Stop a) with the History>Discard the audio is not removed b) however Undo does remove the audio (but not if you've used History>Discard first) The big improvement is that there is no crash 2) The Discard in the History is grayed out and inoperable while recording is active so one cannot get a crash a big improvement. This also makes for good consistency with the Edit>Undo (in both 2.2.2 1nd 2.2.1) as these are grayed out and inoperable while the recording is active. 3) using the Discard in the History after recording makes no discards at all just the same as in 2.2.1 - this is not expected behavior, I would be expecting undo to work it's way through the history stack undoing as it goes. It does empty the items in the History window it just doesn't action the Undos.
This has been problematical for a very long time - testing on 2.0.0 and 1.2.6 shows similar erroneous issues (slightly different in both cases). In 2.2.0 the Edit>Undo button is grayed out while recording - in 1.2.6 it was not (but it didn't work)
Build 4ef8da8, same as Peter's. Using History undoes the undo ability for different levels and occasionally some displayed audio. Using CMD-Z does undo the whole recording eventually with the last undo as long as not mixed with History operations. History seems to give inconsistent results where sometimes it affects the displayed track and other times not. It's hard to know what it'll do especially if not on a new instance of Audacity. Mixing using History with cmd+z gives inconsistent results as well.
I think we need more clarity in this discussion: 1) Let's refer to "earliest" and "latest" undo items, not "first" and "last." 2) I don't know what Cliff means by "using history" (pressing Discard? Clicking on a row?) 3) I don't know what Peter means by Discard (how many levels?) You can do two things in History: use Discard, or, click on one of the rows. History indicates your present position by making some rows gray -- these are redo items. History lets you change your position with a click in the list. This SHOULD be completely equivalent to using the Undo or Redo command some number of times, and so SHOULD affect the display of the project. History also lets you Discard the earliest undo item or items, but not any item at or after the present position. This other use of history SHOULD NOT change the display of tracks.
My more mature version of the fix for this is now completed in 2.3.0, at: https://github.com/audacity/audacity/commit/517bdf1ba863c1160dd699e66c31b43804671a8f Please test!
Tested in accordance with Paul's Comment #19 with a fresh build commit e6d069. I recorded about 30 seconds then edited with 2 deletes and one Normalize. Clicking on a undo line in History is reflected properly in the waveform display. Clicking discard deletes the earliest item in History which is labeled as the "Recorded Audio". The only odd thing in this case is if the user is not 100% in tune with how History "should" work they could be very surprised when they have highlighted an entry other than the first and clicked on "Discard" expecting that the action would be on the highlighted line. I realize that the manual clearly explains what would happen when clicking Discard, but it still looks strange to be able to highlight a line and click on Discard and have it discard another line instead. It seems to me that the highlighting should be disabled so the user isn't confused in this way.
Tested with the same build as in previous comment, but this time in accordance with the "steps to reproduce" and it seems to now work as expected with undo available all the way back to the point of creating a new project and redo also doing the reverse. Undo/Redo works normally from keyboard or History.
The questions about discard working properly and being clear to the user are important, but not the point of this bug report. The important thing is not to have parts of a recording undo with other unrelated changes such as adding labels or moving sliders or resizing of the track window or change of selection, that happened during the recording. It is important to verify that, but also to verify that no other strange things or crashes also happen when you exercise undo and record and redo this way.
I've tried many combinations of changes and so far all works as intended. As far as I can see here the bug looks fixed. Be good to have confirmation from Peter.
(In reply to Paul L from comment #20) Testing on macOS 10.13.3 High Sierra with e094dcb.dmg 23Feb18 I confirm that at step 6 in the Steps to reproduce, the entire recording is deleted with the first undo - which is I believe intended behavior (rather than the partial removal we experienced earlier). It took me several more undos to get the project back to its "original empty state" with the various label additions/edits and the label track itself. So changed the flag as OK on Mac. ----------------------------------------------- There are of course much easier and more transparent ways to remove the recording and the label track by using the X in their TCPs - but I do realize that the undo stack has to work properly. ----------------------------------------------- I broadly agree with Cliff's comments in Comment #21 but that (the behavior of the History window) is a separate issue. I speak as the person who documented a lot of that (with a great deal of help from Gale) in the manual - and I still find the History window a dark, opaque, mysterious section of Audacity - and one I would never tangle with personally for production use, I find I can manage perfectly well without it. I only ever venture there for testing and documentation purposes ...
Testing on W10 with nightly 2-3-0 20180225-68 As with Mac: I confirm that at step 6 in the Steps to reproduce, the entire recording is deleted with the first undo - which is I believe intended behavior (rather than the partial removal we experienced earlier). It took me several more undos to get the project back to its "original empty state" with the various label additions/edits and the label track itself. So changed the flag as OK on Windows. I'm pretty confident that it will also work OK on Linux too - but I would prefer to see it tested on Linux before marking this as RESOLVED
It doesn't look quite right here, but a definite improvement. Following the steps to reproduce, the recording is "undone" on one click, which I believe is the main point, but as suggested in step 4, I adjusted the Pan and Gain during the recording. These commands are still in the Undo History, even though there is no track for them to refer to.
(In reply to Steve Daulton from comment #27) In the light of Steve's comments I have raised a new bug for the residual issue he raises - P5 Bug #1849 An accordingly I shall close this one as RESOLVED
(In reply to Peter Sampson from comment #28) I agree with this course. I am aware that the possibility now exists that you can make vacuous undo items, if you adjust the sliders of the new track being recorded. I don't have a good solution yet. I think this won't happen if you adjust sliders of some other track that already was there before recording.
