“Discarding undo/redo history” issue

I’ve upgraded to 3.6.4 and have discovered enormous problems with the “Discarding undo/redo history” issue. From what I can tell, there seems to be no success, by the community, in solving the problem …or am I missing something? If anyone has a work-around for this, please advise.

I am processing series of 20-30 ½-hour tracks. When I close Audacity, it can take a half-hour, or more, to go through this “discarding” process. There seem to be no options to turn off the history (which I’d gladly sacrifice to avoid this). It seems that some basic housekeeping, regarding functioning, needs to be done before moving on to more features.

I have a Win10 machine with a 2TB HDD and 32GB RAM.

Yes. Audacity makes complete safety copies of the “before” work as it’s making corrections and edits. I said I would give a lot of chocolate to be able to delete some or all of those backups as they swamp the machine. There was supposed to be some attention paid to a different method of doing this, but so far no joy.

Can I guess you’re not editing a fun podcast for the family trip to the beach? I don’t know that Audacity was ever intended to be a large, multi-track, industrial processing package.

And no, I don’t think anyone is going to post with a solution. I think your job just doesn’t fit.

Koz

1 Like

You’re right: my use of Audacity is not for recording soundtracks or editing/recording podcasts, but nor is it for professional purposes. I use it to process the audio in my video containers, e.g.; MKVs. However, I’ve never noted a limiting purpose for Audacity application.

Interesting that my open-source video processors do have undo/redo capability, for both video and audio, and yet have none of this burdensome unloading of memory, despite having far greater memory demands and time lengths than Audacity. Perhaps, if an Audacity developer looked at how video processing is done, that would provide a clue as to how to better handle this.

What I would ideally like to see is a new Preference setting for the maximum number of entries on the History stack, the maximum number of Undos that can be performed.

For my money I’d make the default probably 10 or 20. To me it makes no sense to enable the user to potentially hundreds of Undos, thereby losing every other intervening edit in the process,

This would be a FIFO (first In First Out) pushdown stack, with the entries that drop off the list being purged at the time rather than on exit from Audacity as is the case now.

I’m not sure that I would consider allowing a user setting of zero to effectively have no Undo capability whatsoever - rather I would look have a minimum setting of 3 Undos say.

I will consider writing a GitHub enhancement request for this.

Peter

1 Like

I agree with your suggestions …except for one: not allowing a user setting of zero. Let the user decide. If they want zero Undo capability, then so be it.

GIMP is the preeminent open-source equivalent to Audacity in the photo editing world. Take a look at how they handle such issues (the “Minimum number of undo levels” can be set to zero):

The compromise: Reduction to three is a simple setting and reduction to zero is more difficult. You have to really want to do that.

You gotta know somebody is going to reduce to zero and then panicky post on the forum to UNDO a vital, important edit/mistake.

Koz

1 Like

If the degree of developer effort is logarithmic, as a function of each level of undo added, then I agree that just getting close would be better than nothing.

However, I wouldn’t consider the high probability that someone might set it to zero, and then scream for help, as reason to make the option idiot-proof, given that others could benefit from having wider options.

Yes, since the last update, this seems to take a long time even with just a single short song. Maybe it was cleaning up backups from some location I did not know about? Hopefully gets a fix, or a less annoying default.

1 Like

I had this same issue a few weeks ago and submitted a bug report here:

The fix applied did resolve my issue, so hopefully in the next update there is a patch for that. The developers are aware of this issue though.

2 Likes

I’m not clear on what fix was applied. Am I right that a special “build.yml”, for a Mac, is the fix?

I am using the build at the bottom of this page (I’m on Windows, but I’m guessing the issue is fixed on the Mac build as well)

@Dan33185

That fix was applied to the master alpha test build for 3.7.0 two weeks ago - so will be in that release.

Thanks for reminding us of that issue that you raised :sunglasses:

Peter

1 Like

I’ve been testing this fix over the last few days and, unfortunately, I see no difference with this fix. Let’s hope that the developers see a need to address this very disruptive behavior.

I have found a less-than-desirable workaround. At the end of processing, I use task manager to kill Audacity. Doing this, I can avoid the enormous time-sync and computer lock-up caused by the unloading of the undo/redo and checkpointing activities. When I restart Audacity, an “Automatic Crash Recovery” screen appears and retained projects can be discarded instantly. If I find evidence of corruption, in Audacity, I’ll just reinstall it.

@DeannaAudio a very cute workaround :sunglasses:

Peter

Yeah …too bad that option to “Discard” the “New Project” isn’t provided under the “File” menu, instead of a recovery from a forced “crash”. Then, you wouldn’t have to close Audacity to clean it out. If you don’t clean it out, it gets increasingly slower as you try to work on new tracks.

I should add that, if anyone is going to use this workaround, it is a good idea to go into the SessionData folder (where Audacity stores the project files) and delete the project files. Otherwise, they will accumulate as a result of improper closing of Audacity using task manager.

@DeannaAudio

You shouldn’t need to do that.

Provided you use the Discard Selected button (non-default) with all recoverable projects selected:

And then confirm with the Yes buuton (also non-default)

Then Audacity should clear out the Session data folder for you.

=========================================================

I do notice a slight oddity in the second image above where it looks like focus has been transferred to the default Recover Selected button. However clicking No in the secondary dialog returns focus to the Discard Selected button.

This looks to me like a minor cosmetic bug which I shall loge when I get some time later.

Peter

1 Like

You are right. Thanks.

1 Like

@DeannaAudio

On second thoughts clearing out the SessionData folderstraight after the forced exit from Audacity
a) avoids the annoyance of going through the recovery dialogs on next launch
b) releases the disk space immediately rather than waiting for next launch (which may well be a fair elapsed time)

Top tip: This task can be made easier by creating a desktop shortcut for the SessionData folder.

Peter