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).
Please also see can't reopen a saved project - #48 by Gale_Andrews I am very satisfied that a standard unprotected option to allow an unmodified import to keep the project clean poses unacceptable risk.
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.
Would Steve or Gale be willing to commit an experimental (may be in a separate branch) “Advanced Warnings” button on Preference’s Warnings panel which (for now) only exposes a switch for “quit nagging me to save a not-very-dirty Project” (with the explanation that simply Importing an audio file would be considered not dirtying the Project)? Optionally, there could be some checkboxes to allow Normalize and Amplify (and/or others) do not dirty the Project.
We could also add an option here that Importing an audio file put a filesystem lock on it so that the inadvertent user could not delete a file on disk while it was open (in filesystem terms) in Audacity.
I did some poking around and Project doesn’t really have a proper concept of whether or not it’s dirty. It sets a flag mDirty if you Project::PushState(), but that flag is essentially never unset. If that flag is to have a real meaning, then Project::Save() should reset it. It is telling that the region of code in control of the Save Changes? dialog asks UndoManager and checks a preferences flag, but does not reference the mDirty flag.
UndoManager is closer to knowing whether a Project is dirty, but it doesn’t make any distinction between view-only state changes and state changes which effect the data in the Project such that the output audio or metadata has changed.
I think that the concept is one that is too difficult to maintain as a flag that needs to be updated by N places and Project should get a method Project::IsDirty() or the like to query that – even if that method just forwards to UndoManager::UnsavedChanges().
So as far as I can tell this is a non-trivial, although not monumental, task.
Sounds good to me, but I think that I can anticipate Gale’s response that some user will be strapped for disk space and, in their mind, need to delete the master immediately.
“View only” state changes should not be pushed onto the Undo stack because there is nothing to undo. A couple of such “no-op” pushes were removed recently. If you find others then they should probably be removed also.
Currently we have just one development branch of Audacity, and consensus among the developers is that, at least for now, they wish to keep it that way.
I’d certainly be willing to consider committing such a change if we can come up with suitable wording that makes it clear what’s happening.
I’m not at all keen on that. In this case both the project and the project audio data have changed. I think it’s far too confusing to make exceptions for a selection of audio processes, especially as the user demand appears to arise from misunderstanding the concepts involved.
Proposal
Add an “Advanced” button on Preference’s Warnings panel which opens either a new hidden panel (my preference) or dialog that (for now) only exposes a switch for “quit nagging me to save a not-very-dirty Project” with the explanation that simply Importing an audio file would be considered not dirtying the Project. All advanced warning switches will be ON by default.
If it is a new Preferences panel, name said panel “Preferences: Advanced Warnings”; if a dialog, use the same wording for the title of the dialog. At the top of either panel or dialog have some generic explanatory text about why automatically dismissing these warnings is for advanced users only.
Wording
“Advanced Warnings…” (proposed exact wording for button, note the use of the plural which assumes imminent addition of other advanced warnings*****).
“Preferences: Advanced Warnings” (proposed exact wording for Preferences panel name or dialog title).
Generic explanatory text and pseudo-section label (depending on whether panel or dialog, something along the lines of):
“Not showing these warnings could lead to the loss of data or your hard work.”
“Show Warnings/Prompts for”
“quit nagging me to save a not-very-dirty Project” (potential wording: “Saving Project if only Importing audio has changed it.” Optionally, followed by a 2nd/multiple line(s) with explanatory text.)
Optionally followed by an indented section with one or more checkboxes controlling other actions which currently make a Project dirty but which the user might want to ignore (Normalize, Amplify etc.)
***** Potentially: Nagging “…really sure…” in re. AutoRecovery files
I can’t figure out how to hide the panel from the tree on the left and I have not figured out how to make the new button open the panel. I already have the code working in Audacity 2.0 to honor this checkbox but, as tcbrack points out, discerning “dirty” can be accomplished in (at least) two different ways and we need to decide how we want to proceed.
I’ve thought about a lock on imported files myself. But we’ve had regular complaints on Windows after we updated to use FFmpeg 2.2.2 that after importing a file using FFmpeg, that file is locked and can’t be deleted until you quit Audacity.
For some reason I no longer see that happening in HEAD, which is great. But it does show you that people do delete files as part of their workflow, and so shows the risk of making it too easy to remove the “Save changes?” prompt.
Might this not be better in your own fork of Audacity, Ed? Then we can see the changes and it’s easy to merge it into Audacity master. As it is now, we have to diff your files to look at the changes.
I think it is simpler not to change the concept of when a project is dirty. This saves us trying to explain to the user what the different concept of dirty means.
I’ve seen other use cases too for performing what we would call “edits” to the project but wanting to quit without saving changes. Using labels to look at beats or to see where audio below a threshold occurs comes to mind. In short, the only way to stop all the complaints is to give them want they want - an option to hide “Save Changes?” without any qualifications.
I too think we want advanced preferences to be extensible to include other options, so they should be in their own pane. We have to decide if we want one button for Advanced Preferences that is visible wherever you are in Preferences, or “Advanced” buttons where needed in individual Preferences panes.
I think it’s more common just to have one “Advanced” button, but in the case of this “dangerous” option to hide “Save Changes?”, a button only in Warnings Preferences would be harder to find, so it may be the best plan.
Also in http://bugzilla.audacityteam.org/show_bug.cgi?id=1368 Peter wants the warning about saving empty projects to be capable of being turned off by a checkbox in the warning. This would reverse an earlier decision that this was too risky for naive users. I would in fact contend that even unchecking this warning in Warnings Preferences should have a prompt explaining the consequences of turning this warning off. So - although I don’t expect Peter to like the idea - moving this “Saving empty project” warning into Advanced warnings might be an idea. It is much safer and means we can have more than one “advanced warning” to populate that dialogue.
Naive users are not going to figure that they could “see better” by zooming on the vertical scale.
