Audacity currently considers any file opened to be the start of a project and immediately considers that project to be dirty.
I use Audacity for playback and analysis, but not editing of audio files as part of my work. In this use case, the save project prompt that appears on exit is a nuisance.
To solve this, I forked the project on Github and created a version that had a visible option to never ask on exit to save a project ( see closed pull request #134 ). I was told that the Audacity team on the whole would disapprove of such a feature as being too risky a thing for a user to enable by accident. Many projects implement such a setting, but I can certainly understand wanting to keep the program safer for novice users and people with significant time investment in their projects.
So, my follow-up idea is to have an option to consider a project consisting only of imported, but unmodified, tracks to be “clean” and not ask to save the project. In this case, the damage to a user’s work is rather limited; they can only have added a set of files to the project, but not made any other modifications to the project. Would that be an acceptable feature for Audacity?
I have not looked extensively through the codebase to see how difficult this would be to implement. There doesn’t seem to be an explicit concept of “clean” v. “dirty” projects from my brief foray.
Obviously, I would program the feature myself and issue another pull request.
I don’t much like it either, but it has nothing to do with dirty or clean. Audacity is not a “wave editor.” It’s a Project editor and no matter how many sound files you Export, Audacity considers you not having “saved your work” properly until a Project is created.
Actually it does
but you’re right that it has nothing to do with whether the imported file has been changed.
“Dirty” / “Clean” in this context refer to the “project”. A “clean” project is one that has no “history” since it was opened.
One thing that I’m not keen on, because it obscures what is actually happening, is that “File > Open” allows you to “open” an audio file. That’s misleading because what’s actually happening is that Audacity is “importing” the file into a project. The project is now “dirty” because it has in it’s history the “Import”.
There is a very simple workaround that requires no code changes, just “undo” the history (Ctrl+Z) before you close the project. Actions that do not change the project should not be written to the history (I removed some such actions recently).
So, for example, if you import a WAV file, that is written into the project history. If you then view the spectrogram, and run “Plot Spectrum”, and view the Waveform (dB) view, and zoom in and out - none of that should be written to the project history because none of that has change the project. The project thus has one and only one item in its history, which is the import, so a single Ctrl+Z undoes the entire project history and you can close the project without the warning.
For various reasons, Audacity has a very high proportion of “novice” users. Many of our users, when they first use Audacity, have never used any audio recording / editing software before.
That addresses part of the problem, but I think it goes too far in one respect and not far enough in another.
Looking at the broader picture, there is a significant difference between “not changing the project” and “not modifying the audio”. Many actions may modify the project without modifying the audio (labels, changing the track order, track pan and track gain, editing the metadata, …). A user could do a lot of “work” on a project without editing any audio.
I think it would be reasonable to allow a project to be closed without warning if the only item in the project history was importing one audio file.
I think it would also be reasonable to allow closing the project without warning if all that has been done is opening one audio file and exporting it as a new file. Currently, such a project would have two items in the history: The Import, and writing metadata (even if the metadata has not changed or is empty).
I also think that it would be reasonable to allow an empty project to be closed without prompting to save. For example, if the user deletes all tracks in the project, then I think they should be able to close the project without being prompted to save it.
True. As far as my own case, I can just keep the option that I made. I just thought that it might affect a significant fraction of Audacity users and improve the user experience.
I can respect that. I’m certainly not advocating taking on the mentality of VirtualDub which used to have an option to enable confirmation dialogs that would insult the user and pop up repeated dialogs to confirm that the user wanted to be sure about the program giving them a chance to save changes or double check settings – and it was common for a single process to take four hours in VirtualDub.
I don’t want to change the default experience, just provide the option to allow certain actions to not affect the “clean”/“dirty” status of a project.
Okay. It sounds like the Undo/history system is fairly well developed. Based on a new preferences setting, the UndoManager::UnsavedChanges() method could consider a history of only an import to be not a change requiring a save if and only if the project is new. This would keep from prompting users to save who have opened a project ( distinct from my case of importing a file ) only to view it and make no changes, as well as my case where a single audio file is imported and the implicitly defined project not modified.
I think I recall from the code that an empty project is considered “clean” unless one of the preferences is set to consider an empty project dirty. So an empty project will not prompt, assuming that the user’s preferences are set appropriately – I forget whether the default is to prompt on empty or not.
The same objection remains as before - users delete their files after importing them. That is a significant part of the reason why we had to implement the warning for importing uncompressed files, which are capable of being “read directly” without copying their data into the project.
So I think that the original pull request is still a big “no”.
Or perhaps if the entire multi-track project’s audio has been exported, but that may be harder to detect.
That can be done now if you disable the default warning for saving empty projects.
To me the quick answer to this is the one I proposed in the pull request - make “Ask to save on exit” a preference that is respected in audacity.cfg but do not expose it in the Preferences GUI.
The suggested preference to the effect that “imported files without other undo history are clean” will not help those users I know who for example import a file and normalize it to “see the waveform better” then want to exit Audacity without prompt.
Plus, any visible preference is open to naive users enabling it without knowing what they are doing.
Okay. That is interesting. Clearly, it is done with Audacity or you wouldn’t be implementing features based on it, but that doesn’t seem like a safe workflow.
I closed the pull request after seeing the feedback on Github. I’m not looking to reopen it, at least not as it stands. I’m looking for a solution that fits with the goals of the project and community if that’s possible.
Alright, I’ll remove the visible preference and reissue the pull request.
Related to the concept of a hidden configuration option: does your configuration system support comments in the config file?
Thanks for that. Like Steve I think there may be “some” exceptions we can make where we could hide “Save changes” but “completely safe” exceptions would not help use cases where Audacity is just used as a player or viewer.
I tested it and it worked fine for me. I would likely use this if there is general agreement to commit it. I have on a couple of occasions lost work because I am so used to saying “No” to “Save changes?” when testing Audacity that I have said “No” when actually using Audacity for editing.
You can at the very least write a string like the currently unused AUDACITY_PREFS_VERSION_STRING which will appear in audacity.cfg at every launch of Audacity.
How to publicise hidden settings is probably part of the discussion around committing your change. There are a few “safe” hidden settings already like BeepAfterDuration and BeepFileName for the sound that can be optionally played after longer processes complete. I would like to see more of these hidden settings because they can make Audacity much more customisable without us worrying about overloading the GUI preferences.
Ideally I think we would have some kind of “Advanced…” button in the GUI Preferences that give you an interface to edit “hidden” preferences in audacity.cfg. It could have a warning about “voiding your warranty” or “here be dragons” like Firefox’s about:config.
We could instead just list the hidden settings somewhere in our documentation (Manual or Wiki) but then users could make a bad manual edit to audacity.cfg and get themselves in trouble that way.
I don’t follow.
if Audacity is “just used as a player or viewer”, then you “open” (“import”) a file, view and/or play it, then close. That is “completely safe” and as I wrote previously, I think we could disable the warning in that case.
It is not safe because the user may already have deleted the file. Do you remember how often that was being complained about before we had the warning for import of uncompressed files? I do - barely a day went by without it. You can see from the Manual the number of places we say not to delete, move or rename your file.
The “ordinary users” who delete their imported files are the problem. Hiding “Save Changes?” even if there is only one imported file and an otherwise clean Undo Stack will cause them to lose their work.
If we want a solution for “ordinary users” then I suggest we can give them an advanced configuration editor. There has been a problem for years that we are reluctant to add useful preferences for fear of overloading the interface. An advanced configuration editor would be an answer to that. Or it could simply be another standard interface with checkboxes behind an “Advanced…” button. The important thing is that it is not part of the main preferences interface.
Either way, we can’t have an option to disable “Save Changes?” until it’s in the codebase.
Which could just as easily happen if they played the audio in some other “media player” couldn’t it?
If they are treating Audacity as an “audio player” as you suggest, then why would they delete the file if they want to keep it? That doesn’t make sense to me.
Yes I remember that, but that was when the user was saving the project, then deleting the file without realising that the project depended on the file. That’s a different issue from just playing or viewing the file.
For example I can remember a number of cases where users imported a file then deleted it immediately, thinking the import automatically saved it then they could close Audacity at once and come back later to edit it. I’ve just looked up one of those:
But I thought Audacity was a file conversion utility!!!
But that’s ridiculous. Do any applications do that? How are we giving them the impression that such bizarre behaviour could or would occur?
Even if Audacity was a file conversion utility, it makes no difference. If they don’t save their “converted” files anywhere, then why should they expect the files to be saved?
It’s impossible to make anything totally foolproof because fools are too inventive.