I’m in favor of adding a “do it this way and don’t ask me again” option to the “save if dirty” dialog. I’m even more in favor of redefining “dirty”. This combination is the second most popular feature I give my clients. A Project is always clean until it’s audio is modified (simply importing audio does not make the project dirty, recording into a project does). I have gone even farther and added a few toggles in Preferences which gives the user the ability to say “these actions which normally make a project dirty do not do so” (Normalize etc.). I WOULD NOT suggest this for the novice or casual user of Audacity.
I absolutely abhor “hidden” options! There is at least one pair of these (as Gale pointed out – “play a wave file” instead of the system the beep and the path to said wave file). This entire section of code is unreachable unless one knows the secret to modifying the configuration file. One way or another we must get past the (in my mind irrational) fear of expanding Preferences.
It’s really easy to make Preferences resizable and allow scrollbars. It’s easy to add new panels; the panel tree to the left already has the ability to display scrollbars as needed. Personally, I would not bother with an “advanced” button, exposing everything ubiquitously. What I would do was to think carefully about the organization of each panel; currently some of our panels have multiple sections (none of which are very complicated). If the addition of new Preference items causes a panel to become excessively long consider splitting that panel into multiple panels not multiple sections. Additionally, group a panel’s controls logically but move less frequently used items toward the bottom; this applies to both items in a section and sections in a panel.
I think I’m close to your position on this Edgar, but I’d rein it back a bit.
For illustration, consider this fairly extreme case:
Import 30 audio files (perhaps recordings of individual instruments)
Arrange the audio clips into 8 tracks and carefully position each audio clip.
Delete the empty tracks
Carefully adjust the track Pan and Gain sliders for each track to create a balanced stereo mix
The above steps could take an appreciable amount of time and effort, and in this case I’d want the project to be considered “dirty”, even though no audio data has been changed.
I previously wrote:
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.
Having considered this, I now think it reasonable to go a bit further and allow any number of files to be imported, thus, in the 4 step project above, after step 1 (import 30 files) the project is still considered “clean”.
I can see many (less extreme) cases where this would benefit users, for example, if you just want to visually compare the waveforms of 2 or 3 audio files.
@tcbrack
As you can see, there are divergent opinions about this, but I hope that you see that there is a thread of underlying agreement that we all want Audacity to strike an appropriate balance between convenience and safety, and that we all agree that improvements can be made. Unanimous agreement is not required for a new feature to be implemented, though of course we would hope that all new features are broadly welcomed by users. At the end of the day, the developer that writes the code must decide what is appropriate.
But it is absolutely unsafe for naive users if we allow easy turn off of “Save Changes?” however “dirty” the project and regardless if user has exported the project audio.
But your clients are advanced users. Not the sort of users we are trying to protect from their own mistakes.
Once again, that will not help users who delete their files after import, thinking the act of importing the file has “converted” or “saved” it. Allowing import of a file to still show the project “clean” would considerably encourage that misconception.
Hidden options are better than no options. We can add the hidden option to disable save changes now. It is possible to document that hidden option if we want to. That would be better than having no useful answer to the abusive messages we get about this from some users (which I usually have to deal with).
There is no way we can enable a safe visible preference now to disable save changes because that would require extra code changes (significant changes if we make one criterion to disable save changes that all audio has been exported).
The developers are worried about making Preferences too complex and extensive especially while we have no Help button in Preferences.
I think it would be reasonable to have a simple preference to disable save changes available via GUI, but it is far too dangerous to have it in the main Preferences pane.
As I said I would be happy enough to have a large number of extra preferences including “dangerous” ones available behind an Advanced… button or similar with a warning not to change these unless you know what you are doing. This is standard practice in applications. It would be simpler and to my mind arguably better than redefining what is dirty and what is clean.
Again, advanced preferences is more coding and decisions on what preferences go in there. We cannot do that now. We can apply tcbrack’s changes now and make things better for users who are able to modify audacity.cfg.
It’s the same issue as thinking pressing [X] on a track saves the track. Needless to say these users will be exiting Audacity by the window close button.
Even Ubuntu has dialogues where there is no save button and pressing window close saves the settings. And yes I know that is saving settings and not a file containing data.
I wonder who is going to document these complexities about when a project is clean or not. Will it be obvious to users what actions make a project dirty or not without reading the Manual?
Having given this full consideration, taking into the for and against arguments from Gale and Edgar, I’m in favour of this change. +1
I’m also in favour of Audacity not adding “Edit Metadata Tags for Export” to the history if the Metadata Tags are unmodified. This would require checking that the Metadata Tags have not been modified, and would mean that exporting does not make the project “dirty” unless the Metadata Tags have been changed.
I think that these two small changes would go a long way towards resolving the complaint about Audacity “nagging” users to save projects, without exposing new users to unreasonable risk.
A fairly standard method is to add a star to the tab or window title when the unit in question is dirty. See CodeBlocks, Eclipse, gedit…
Having a rigorously defined concept of what constitutes a dirty project allows the program to only ask when necessary, and keeps users from developing muscle memory that causes that prompt to be useless.
It might simplify things all around if Audacity had a distinction between a Project and the files that are currently displayed. Opening an audio file should be distinct from implicitly creating a Project contrasting that file. This would more cleanly delineate between the various use-cases of the program and a set of open files could fairly easily be formed into a Project at will.
I agree at least that this is more understandable than some of the other criteria proposed for disabling save changes. Does unmodified mean “no undo history except import”? If so that will still not help those who import the file and amplify it or normalize it to see it better, which is a common action from the messages I’ve seen.
Or does unedited mean “not changed the file length”?
And are you going to implement these changes for 2.1.3?
I am still -1 to displaying such an option in the main preferences pane unless you are going to somehow provide other protection against users deleting files after import. A message that says “This is what this option does, do you really want to do it?” will not be read or understood. We know that perfectly well from experience with dialogues for saving projects and exporting with unexpected extensions.
Because I (and I think Edgar) have both suffered from that “muscle memory” problem I do longer term want some GUI (visible) option, but not in the main Preferences pane.
For naive users it remains IMO absolutely necessary to ask after importing a file and doing nothing else. As I often say, we are not Ardour. We have many more users than Ardour.
Audacity does not “open” audio files. It imports them into projects. Everyone here including Steve has been saying that for years.
Another alternative is to have a “player mode” of Audacity with almost no editing options. Normalize and Amplify would be allowed.
The word used was “unmodified”, not “unedited”.
An “unmodified” track is one that has not been modified. That means, not cut, not amplified, not normalized, not resampled, not edited, not compressed, not expanded, not moved, not trimmed, not truncated, not clipped, not processed in any way.
So what are you suggesting? I don’t believe that you are seriously suggesting that we should allow novice users to process their imported tracks, then close the project without being prompted to save, or are you?
If the user wants to view the track ‘bigger’ without modifying the audio, they should zoom in vertically. If they do not understand the difference between zooming in and amplifying, then they are clearly a novice that needs all the safeguards that we can provide.
To be clear, if the track is modified by amplifying or normalizing the audio, and the user attempts to close the project before it has been saved, then the user should be warned. I can’t believe that you are questioning that while at the same stating concern that users might “lose work” because they think that a file is automatically saved by opening it.
Are you speaking as one person or two? Those two statements appear to be contradictory and mutually exclusive. What point are you trying to make? Are you just saying that you don’t want change?
Steve, we must address that case of people “viewing” the file by changing amplitude, or we will only half-solve it, and complaints will continue. Naive users are not going to figure that they could “see better” by zooming on the vertical scale.
So either we allow amplitude change to keep the project clean, or we do allow a simple on or off preference to hide “Save changes?”
As I said, I see the solution as hiding a simple on/off option sufficiently well that it will not be possible for novices to do it by accident. An option only available by editing audacity.cfg fulfils that. An option hidden behind an Advanced… button in Preferences and sufficiently warned would be acceptable to me.
Please see above for why I am questioning that amplifying or normalizing should make the project dirty. But no, I would not do that if it was my choice, unless we made that an explicit well protected option (“well-protected” means not in the main preferences pane).
And that is why I have always been adamant and purist that Audacity should not really have an open command that works on audio files. Open should be purely restricted to Audacity projects - and Import should be the only command that brings audio files into Audacity. Drag&drop would be fine too, but only into an already open project (as then that is an implicit Import) - NOT onto Audacity icon/shortcut/.exe
It is clear, yet again, from this thread that allowing Open > creates confusion and misunderstanding.
As you know I always like things that “does what it says on the tin” - and Open > is somewhat a sleight-of-hand, hiding what is actually going on from the user
To me, if File > Import > Audio… left File > Save Project… greyed out, it gives the impression that Audacity has “opened” the file.
And I still feel doing that encourages the misconception that it is “safe” to click Audacity’s window close button and then Audacity “saves” a copy of your file that you just deleted to save disk space.
We can add the hidden option to disable save changes now. It is possible to document that hidden option if we want to. That would be better than having no useful answer to the abusive messages we get about this from some users (which I usually have to deal with). 
