Difference between revisions of "Completed: Proposal User-safe Aliasfiles"

From Audacity Wiki
Jump to: navigation, search
(a demo pic)
(bug 308 rejected patch on bug 26)
Line 72: Line 72:
<b>8Mar11</b>created a Bugzilla bug so we could exchange patches:<br>
<b>8Mar11</b>created a Bugzilla bug so we could exchange patches:<br>
<b>20Mar11</b>bug 308 was rejected the patch can be seen as "proof of concept" on:<br>
On that bug I uploaded a patch which implements my concept:<br>
On that bug I uploaded a patch which implements my concept:<br>

Revision as of 19:58, 20 March 2011

Proposal pages help us get from feature requests into actual plans. This proposal page is about making use of aliased audio files safe in Audacity.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.

  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

The Problem

  • Currently using aliased audio (we reference it rather than copy) is the default in Audacity.
  • This has caused some users to lose/damage audio projects. They mistakenly believe the Audacity project contains everything itself and delete/move/rename the original audio. Use of the word Import when actually referencing external aliased audio files contributes to this mistaken belief.
  • The problem is exacerbated by the fact that the waveform graphic in the track remains visually intact, but there are gaps produced in the audio.
    • GA: If you edit the audio, it will be visually silenced too, but what this means isn't explained to user.
  • And further exacerbated in that the user gets no warning/error message to tell them that they have an incomplete project. This is Bug 26.
    • GA: This statement now only applies if they delete audio while the project is open then edit/export without playing, without saving a project or without clicking File > Check Dependencies. The only way round this I can see is for Audacity to lock the dependent files or we warn on import (by one method or another).

Ed 7Mar11 I appears we are very close to being ready for a stable release. Is this discussion going to impact a stable release? If so, what is the best way of addressing the issue?

  • Leave the code as-is i.e. "faster" being the default
    • then make no other changes to docs, warnings or dialogs
    • text changes only to docs, warnings or dialogs
  • Change code to "safer" being the default
    • text changes to docs, warnings or dialogs
  • Additionally, code changes to dialogs to offer a warning which may be permanently turned off and a way to directly set prefs settings from dialog

Getting a programmer Developer involved will be necessary to review any code we might offer--I would be happy to do some mock-up patches if needed.

Additional Information

  • Lower down the page there is a table of speeds.
 We have several proposed solutions here.  Now split out by person.
 Please keep the proposal sections to proposals by that person, and not 
 discussion of those proposals.  Please tidy this page if you can.

Proposal (Gale)

  • Preferred: Copy-in is default in 2.0, but only if we have a warning dialogue before importing files of 30 seconds or longer that offers referenced audio and explains the benefits/dangers. Choice is link this time only, link now and always, or copy-in. "Don't show again" checkbox. However "link" as a word implies security and is too dangerous.
    • Warnings for editing and exporting when aliased files are missing must be added (they are P2).
    • P4s for opening and locking aliased files whilst the project is open, and an immediate warning on detecting loss of those files.
  • Second choice: If we don't like warning-on-import, then referenced audio must be default, or too few people will benefit from it. Primary protection is afforded by file locking (with immediate warning when file loss is detected), instead of by warning-on-import. P2 warnings are mandatory, exactly as in "Preferred choice".

Proposal (Peter)

as understood by James. Please edit and correct

  • Copy-audio is default in 2.0

If we also have enough time to add:

  • Copy/Link-to preference now only affects drag-and-drop.
  • Copy/Link-to is selected per import, and follows from the menu item used.
  • Naming of menu item is no longer "import" in the case of load-on-demand. This is to help make it clear that the file is not copied.

Then we could have Link-to-audio the default.

There is also an alternative (2) proposal about tiered preferences.

Proposal (James)

  • Copy-audio is default in 2.0
  • For 2.0 we also fix up bugs relating to silently using silence when files aren't found. Audacity complains when Audacity actually needs to use data files that aren't there. We try to do this with a modeless dialog where it makes sense, so that actions could continue, since that seems to be the rationale for the silent silencing.
  • We aren't doing any proactive locking or looking for files to check they are there.
  • Post 2.0 we add context sensitive help to the preferences to explain what is going on and what the option does.

Proposal (Martyn)

as understood by James. Please edit and correct

  • Copy-audio is default in 2.0
  • no opinion yet expressed on other matters

Proposal (Bill)

as understood by James. Please edit and correct

  • Copy-audio is default in 2.0
  • We also fix a bug with reading CDs on Mac.

Proposal (Koz)

as understood by James. Please edit and correct

  • Copy-audio is default in 2.0

Proposal (Ed)

7Mar11 I added a new section on the Talk page--at the bottom--to talk about the dialogs and revisit Bill's questions of early 2010.

IMHO the current situation is fraught with danger. If we do nothing else I would prefer the default be Copy in (safer).
8Mar11created a Bugzilla bug so we could exchange patches:
20Mar11bug 308 was rejected the patch can be seen as "proof of concept" on:

On that bug I uploaded a patch which implements my concept:
My proposal is that we open a dialog at some point (opt 1--only if prefs have NOT been changed; opt 2--regardless of changed prefs)

  • [best] the first time a user imports affected data
  • [poor]any time prefs have been initialized (as on install)

The dialog could be something like this:

Some audio may be imported without copying the data into your Audacity project. The default setting is "Read uncompressed audio files directly from the original (faster)" and the other is "Make a copy of uncompressed audio files before editing (safer)". [best Your current preference is set to safer|faster.] | [poor The default safer|faster is current to be used.]

Do want to leave this setting as it is?

{Yes}     {no}

There are potentially serious consequences when choosing to use the faster mode.
[...a potentailly long and techical description of dependencies which will likely scroll off-screen...]

After considering this information do you wish to set your choice to
{safer}     {faster}

Proposal (Vaughan)

as understood by James. Please edit and correct

  • Link-to-audio is default in 2.0
  • Warning about aliasfiles should be done at save/export.
  • We aren't doing any proactive locking or looking for files to check they are there.

Votes (Community)

  • Steve Daulton, Paraic O'Lochlainn, Peter Sampson and Bruno Gravato all in favor of Copy-audio as default.
    • Peter 4March11: on the recent thread on the forum last month Bill Wharrie and Greg Kozikowski also voted in favor of Copy-audio ("safer") as the default.

Proposed Feature

Some combination of:

  • Make copy-audio (safer) the default.
    • Make copying audio faster than currently. One bottleneck may be sample rate conversion.
    • Gale: Another is the Windows problem since 1.3.8 of much slower waveform drawing
    • Do copying 'in the background' so that the safer mode works with on-demand.
  • A warning when importing using "read directly"? This could be turned off in the warning dialog or in Warnings Preferences. Warn the user every time they include aliased audio.
    • Gale: I favour the "warning" approach (at first import of WAV/AIFF irrespective of Prefs setting), unless copy in can be done *after* OD completes - otherwise I fear the time penalty will be too great. This is my idea (more detail on the Discussion tab):
Project depends on imported files
Your preferences are set to import %s without copying in. This is very fast, but the file(s) must not be moved or deleted.
[ ] Always copy in uncompressed files
[ ] Don't show this warning again
    • Peter 1Mar11: Ed Musgrove suggested the following alternative in an e-mail to me:
      Maybe a one-time dialog with fresh install (or initialized cfg) on import giving the user the chance to go faster. This dialog could be quite detailed in describing the benefits/risks, maybe with two sets of buttons:
      The default import method is set to “safest”. Would you prefer to set this to “fastest”? [cancel] [no] [yes]
      Additionally details about the difference and their implications could be displayed with a link to: http://manual.audacityteam.org/man/Import_/_Export_Preferences and a lot more details, as the first set of buttons have scrolled off the screen!
      Given this information, would you prefer to set this to “faster”? [cancel] [no--safer] [yes--faster]
      • Gale: Seems to be near-identical with my previous idea directly above, just more verbose.
    • Vaughan prefers "read directly" should stay as the default preference, but that warning about aliasfiles should be done at save/export.
  • Audacity could check if referenced aliasfiles are available and warn the user rather than blithely playing silence while simultaneously displaying a waveform. This check could be done on opening a project and a comprehensive error message displayed.
    • Gale: SVN HEAD now has a warning for missing aliasfiles on project opening which Vaughan and Gale are discussing.
  • Better wording/description to "read directly" This confused me (BillW) initially. What's the opposite? Read INdirectly? ("link external file"? SD)

Alternative Proposal

Peter - 17Feb10 - updated 24Feb10 following feedback received

  • Import: this command will always properly import a copy of a file into the project whether it is compressed or un-compressed. There will be no dependencies on external files whatsoever.
    • On first use of of "Import", display an advice message that informs the user of the benefits (and risks) of Linking to alias files - this message should have an option to not be shown again if required.
    • Faster copying and background copying as above in original proposal.
  • Link: introduce a new command (name TBD) this will not import, but will reference external uncompressed aliased files (as the “faster” Preference option currently does).
    • On first use of "Link", display an advice message that informs the user of the safer nature of import and warning them that this takes longer - as well as warning them of the dependency risks of linking to alias files - this message too should have an option to not be shown again if required.
    • Will not link to uncompressed audio files - but will warn the user that compressed files cannot be linked but must rather be imported.
  • Drag-and-drop: will switchably either Import or Link. The current Preferences setting "safer"/"faster" would be redundant as far as the two Import/Link commands are concerned - but could be retained to influence behaviour of "drag-and-drop".
    • Default should be set to the "safer" option for "drag and drop" - to protect inexperienced users.
    • User would get warning message on first use - message depends on the mode that is set.
  • Corollary suggested by Steve Daulton re. "Open": Currently it is possible to Open either a Project or Audio File. But we don't really mean that you can open an audio file, we mean that you can click on an audio file and open a Project with that audio file imported or linked in it. This leads users to believe that, in opening a WAV file or an MP3 file say, they are operating directly on that file.
    • The command Open should be restricted to opening audacity projects only. We could still give the users the ability to attempt to Open an audio file, but then warn them that this cannot be done directly but offer them a chance in the dialog to let Audacity open a project and import the audio file. This should make the Audacity mechanisms clearer to the user.

  • Gale: I think it could be confusing because except for WAV/AIFF the "unsafe" import command would do the same as the "safe" one. Plus, it adds menu clutter. Plus. it's pretty easy to finger slip in a routine operation and choose the "wrong" one.
  • Peter 22Feb10: no more confusing than the current set up surely - except in the new case it would be experienced users not newbies who can become confused.

  • Peter 5Feb11: Although this alternative proposal has the disadvantage of introducing a further command into Audacity, it would give us the advantage of being able to remove the two radio buttons for safer v. faster on the Preferences>Import/Export dialog box.
    • I think this alternative proposal would have the key advantage of clarifying the interface - as the action undertaken by Audacity on the basis of the safer/faster setting is somewhat subtle to the un-initiated. And note that we have a particularly painful initiation ceremony whereby uses lose or damage their project usually irretrievably.
  • Steve 5Feb11: The "unsafe" import (AKA Link) would not do the same as the "safe" one (AKA Import) if attempting to Link to a compressed file brought up a message saying "Compressed audio formats cannot be linked. Do you wish to Import? [Yes][Cancel]". Clicking [Yes] would then open the Import dialogue instead of the Link dialogue.
  • At present we see a lot of users choosing "the wrong one" without finger slipping. On a new installation the choice has already been made and is not visible to the user until they explore the options in Preferences.
    • GA:06Feb11: It's visible when they save the project. The proposal to change the preference to copy-in by default until we have some other solution is equally a decision without asking the user.
  • Linking to an alias file is not the same as copying data from a file into the project. I don't agree that separating two different functions into two different menu items is "adding clutter". I would describe it as "reducing confusion".
    • GA:06Feb11: I doubt "power users" will appreciate the extra menu item even with a shortcut for it. Unless people want to change copy-in behaviour frequently I see no advantage to this proposal versus the other one to show a dialogue containing the preference choice on first import. A Preferences warning "should" be clearer than a menu item that just says "link" or "import" without explaining what that means. If we had a warning on import/open/drag it would stay on every time until user checks the "Don't ask again" box.

Alternative Proposal 2 - Three-tier default Preferences settings

Peter Sampson 28Feb11: Three different default sets of preferences, for:

  1. "complete beginner"
  2. "familiar with digital audio"
  3. "power user"

"Complete beginner" would include the "safer" copy-in choice for uncompressed audio. See further discussion in Proposal Preferences Reorganisation.

Developer/QA Backing

  • BillW 20Jan10: IMO changing the default in Import / Export Preferences to "Make a copy of uncompressed audio files before editing (safer)" would go a long way towards shielding new users from this problem. We could then possibly dispense with "Rule #3" in Audacity for the Impatient (or wherever the "3 rules" are eventually placed).
  • James - I back doing something about making alias files safer, though I am not sure exactly what until this proposal shapes up. Making (safer) the default and better warnings (as long as they can be switched off) both sound good to me.
  • Gale: I'm interested in the possibility of copying in "in the background" by default while OD proceeds, as an alternative to giving everyone a dialogue on first WAV import. On slower, fuller machines though, I doubt the time penalty versus straight OD import will be acceptable.
    • Peter: I support this but this does not preclude us from making the "Safer" copying in as the default as the first step towards this.
  • Peter: I wholeheartedly support the idea of making the "Safer" option the default.
  • Gale: I am strongly against turning On-Demand off by default by the simple means of changing which radio button is default in Preferences. User will then have to find Preferences to learn there is a fast import possibility (which ultimately we want to have for all formats)
    • Peter: But it is the power users who will then have to find Preferences to make their required setting. And it is those power users who are far more likely to find and understand the Preferences settings than the naiive inexperienced users are.
  • Peter 5Feb11: a recent poll on the forum amongst the Forum Crew/Staff led to unanimous support for making "Safer" the default: Bill Wharrie, Steve Daulton, Greg Kozikowski, Paraic O'Lochlainn and Bruno Gravato all voting in favour (Gale did not vote or comment, but his views are expressed clearly here). We spend too much time trying to rescue naiive users who have lost or damaged their projects. We would much prefer to respond to someone on the forum complaining that importing their WAV/AIFF file takes too long - and them we can then give them a trick to make it faster, at the same time warning them of the potential pitfalls.
  • GA: 06Feb11 This assumes people are going to write and complain about slow import. Some definitely do/will but the majority who never RTFM or study Preferences will never get the benefit of On-Demand. On-Demand is not only useful for "power-users". The only place Audacity does not warn the user about aliased files is on import - otherwise it's a combination of user error and probably our warnings could be better. I have to deal with users who delete aliased files too - I have hardly met any who don't accept it's their fault when it's explained to them. I assume you explain to users that in many cases they can recover aliased files after deleting them?

Speed Differences between OD and copy-in

  • Bill:
Test file is 35:40 AIF, 16-bit 44100 Hz on same disk as Audacity project and temp directory.
Test G4 PowerBook 1.67 gHz 10.4.11 G5 dual 2 GHz 10.5.8 iMac Intel Core 2 Duo 2 GHz 10.4.11
OD import 0:35 0:23 0:11
Copy-in import 0:25 0:17 0:19
Amplify linked 1:29 1:00 0:29
DC offset linked 2:01 1:20 0:39
Amplify copy-in 1:04 0:48 0:28
DC offset copy-in 1:20 0:57 0:36
Save after linked w/copy-in 0:53 0:31 0:14
Save after copy-in 0:04 0:11 0:05
"OD Import" is time until waveform is completely calculated and drawn.
"Save after linked w/copy-in" means remove dependencies, and is the total time for the save - remove dependencies plus save project.
There seems to be a definite PPC/Intel divide, with OD being faster on Intel, and slower on PPC. On Intel there is little difference in processing times for OD versus copy-in, whereas on PPC processing copied-in data looks faster.
  • Koz: (paraphrased0 On Mac, I import 2 hour WAVs all the time. OD is the difference between getting the job done or not.
  • Gale: Win 7 and XP machines 1.6 GHz or higher, 512 MB RAM or greater, it takes a minimum of 2.5 minutes to import a 38 minute WAV (with minimum space free of 30 GB out of 65 GB). Takes circa 30 seconds to OD-import and calculate.

    I've proposed on the discussion tab a possibility to force a dialogue on first WAV/AIFF import for everyone irrespective of previous preference. That would make it acceptable (to me) to have copy in as default.

    • Peter 7Feb11: I would be happy to see such a dialogue on first import, but adding new conditional dialogue could probably not be done pre 2.0 due to the current feature freeze - whereas the simple reversal of the default could be done pre 2.0. I would advocate making the default reversal now and then adding Gale's other proposed changes (on the discussion tab)shortly thereafter in the next Betas.

  • Peter 08Dec10:
    • WAV File 24 mins 22 seconds in length – resident on my onboard hard-drive
      Import/linking 49 seconds
      Import/copying 2 mins 19 seconds
      Amplify whole linked file 2 mins 8 secs
      Amplify whole copied file 2 mins 36 secs
      Remove DC linked file 3 mins 17 secs
      Remove DC copied file 2 mins 14 secs
    • WAV file 1 hour 29 mins 30 secs in length – resident on my external USB disk
      Import/linking 1 min 41 secs
      Import/copying 4 mins 26 secs

    These results are insufficient to show statistical significance, however they indicate that it takes roughly 3 times longer to copy the WAV files in compared with linking to them.

    The processing figures are puzzling – the DC offset removal indicates my preconceptions in that processing on a copied in Audacity project is faster than with an external linked project. But the Amplification processing is contra-indicating.

      • Gale 08Dec10: I wouldn't expect consistent speed differences in editing copied-in and aliased files from the same drive. One major benefit from OD is that you can work with the imported file as soon as the waveform drawing has commenced - this is normally a matter of seconds.
  • Bill 09Dec10: Still waiting on Bruno to test on Linux, but this exercise has been very revealing so far. Putting aside my PPC results (with old machines, and looking at the one Intel Mac test I have available), it appears that Audacity is slow on Windows machines in general - not only in copying in, but in processing as well. 39 seconds to amplify a 35-minute stereo track on an Intel iMac, versus 2:36 to amplify a 24-minute stereo track on Windows. Extrapolating that Windows time to a 35-minute track would give 3:38. That's 5.6 times faster on the iMac! What's going on?

Interface Questions

  • Peter 16Feb10: part of the problem lies in the use of the command word "Import" - this undoubtedly, and unsurprisingly, implies to many naive users that they are actually importing the uncompressed audio file or clip i.e. getting a copy of it in their project - whereas the current default setting does not do this for them.
    • Gale: what do you suggest other than the Import / Link distinction below? We refer to "On-Demand Import" so "import" does not imply copying in the data to us.
    • Peter 7Feb11: What I suggest is simply the original proposal of the simple reversal of the default setting to "Safer" - so that for new users, and users who do not alter the setting, the "Import" command always "does what it says on the tin" i.e. actually imports data into the project. And with this setting the Import command would work the same for compressed and uncompressed files thus giving less experienced users some consistency (which is definitely not the case with the current default "faster" setting - this I'm sure leads to use confusion).

  • Peter 16Feb10: the other thing that foxes many naive users is that if they have removed dependent audio files they do still see the full blue waveforms in the tracks in the projects. There is no visual cue that the audio data is missing - this is misleading for the user.
    • Gale: Vaughan and I discussed that at length. User now gets a warning if the dependent file is missing when they re-open the project. The problem with showing silence in that case is the "panic effect" on users from seeing that, and that (as I understand it) if they restored the aliased files while that session was open they would then still see silence in the waveform (even though they could hear it) until they restarted. If they delete the aliased files after re-opening the project then they get no warning while playing (marked as Bug 26) but they will get silence if they edit.

Use Cases

Bill 07Dec10: I hope this is the right place for this.
There is a use case that is particular to Mac - importing directly from a CD. AFAIK Windows and Linux do not support this. Mac does this by "faking" a volume and files corresponding to the CD and tracks. Importing directly from a CD with "read directly" (on demand) simply does not work as intended. You can't click in the cross-hatch wave and get reliable playback. If you try to play from the beginning immediately after the cross-hatch appears you get stuttered playback and wave calculation slows appreciably. If you wait for the waveform to draw, when clicking and playing at various points in the wave there is a delay as the OS reads the data from the CD.

  • OD import and draw wave for a 3-minute CD track: 46 seconds
  • non-OD import and draw: 24 seconds.
  • after OD import then save and copy-in: 45 seconds to copy in and 3 seconds to save project data.
    • Gale 07Dec10: Windows can't mount an audio CD directly and I don't think Linux can. If Auacity reads a file (aliased or not) from a slow external drive (which seems to be similar in effect to what you see) then reading will be slow. I'd suggest the time to import/draw the wave under OD and the poor performance once drawn needs to be raised on -quality (which I've done) whatever we decide about OD being default.

      Of course, copying files in at "save project" stage if you decide to do so negates most of the overall time saving of OD, though I'd argue that if you copy in when you save project you may be "done" and able to walk away. You probably don't want to make the coffee while you are importing...

  • Following up on this, consider the case of the Mac user who want to make a mash-up. Import CD track, eject CD, insert new CD, import track, etc. When they're done they don't really have any of that audio in their project.
  • A radical proposal: Is it possible (and desirable) to have "copy in" the default in Mac builds? Since copy-in is faster on Mac than "read directly", and it solves the CD importing issue, why not?


Peter 17Feb10: Supporting case for the alternative proposal.

I believe that the confusion and user-error arises because with “Import” we have a command that does two different things depending upon:

  1. whether the file to be imported is compressed or un-compressed
  2. an obscure setting in Preferences

And what is worse, Import often (including with the current default setting) doesn’t actually do what many users would expect it to do.

Further, having one command doing distinctly differing things is bad ergonomics.

The alternative proposal will have the advantage that we will no longer need the Preferences setting of “faster” versus “safer” – but the disadvantage of introducing a new menu command.

Key user advantages:

  • It should be much clearer to the user what is going on.
  • It will be harder for the naive user to make a costly mistake .
  • It will not hide the “faster” functionality from the power-user.
  • The documentation can become more straightforward.

Peter 22Feb10: - I have now started a workflow which involves me switching between "safer" and "faster" (I use "faster" for LP transcriptions and revert to "safer" for other work). It becomes tedious to keep switching by repeated access to the Preferences with multiple clicks - and I can never remember which mode it is switched into (there is no visual cue). This use-case would benefit greatly from my proposal of the two distinct commands.

GUI Implementation Idea

Stevethefiddle 18:10, 21 February 2010 (CST)


"Import Audio" would import audio into the project (as with On Demand = off) "Link Audio" would open a browser window called "Link Uncompressed Audio" - this would enable uncompressed file types to be linked to the project (alias files - as when currently selecting "import" with "faster" option.

The "Supported File Types" in the browser window would only show uncompressed file types for which OD loading is possible. In the event of an attempt to "link" an MP3 or other unsupported file type, the following message would show:


Appropriate warnings could still be shown as discussed earlier.

Gale: 23Feb10

  • In the file window that opens from "Link Audio", are you saying that there is only one filter available "WAV, AIFF, and other uncompressed types"? Or also an "All files" filter? Which is default?

    I think the big problem here is the compressed file type warning. How many novices are going to know at this point what a compressed and uncompressed file is? What happens if they click "Yes" - do they import their MP3 anyway? If so this looks like "one command doing different things" too. And if they get to learn the "you can't" is an empty warning, they might well use this to import WAV's anyway. So I think if this is to work, "Link Audio" must be confined to supported on-Demand formats. The menu item should really say "Link to WAV" (if wxMac, "Link to WAV or AIFF"), but the problem with that is, it might encourage people who know they have a WAV to use "Link" rather than import. So how to handle the inability to import MP3 etc. is crucial.

    How does this scheme cope with users who use File > Open or drag files in? Dragging may be a bit geekish but File > Open is novice behaviour. Many will use this instead of import as you know, because they don't understand "Import". If there is to be no preference for aliasing behaviour, should File > Open always copy in, drag always read directly, or only the "Import > Link to Audio" read directly? My own typical workflow is to drag in aliased WAVs, so I would be very inconvenienced if dragging copied in.

    When you say "I use "faster" for LP transcriptions" I'm not quite clear - you mean you alias WAVs you have already recorded in a previous session, but copy in WAVs ripped from CD for example? Certainly your menu item gives user an on-the-fly equivalent way to "change preferences" but is it a common use case?

    You say "appropriate warnings could still be shown as discussed earlier." Which warnings and where? You say "It will not hide the “faster” functionality from the power-user". Leaving aside that not only power users want On-Demand, where is the explanation that tells user they can import WAVs much faster if they use "Link to WAV", but that "Import Audio" will be safer? If they choose "Import Audio", they will not receive the Dependencies Dialogue, so they will not find out that way.

    In summary, I think the "Import/Link" idea is quite powerful, but looks at the moment that it has flaws as a single panacea. It would be compatible with my proposal of a global first time warning for all methods of WAV/AIFF opening if we used it as an on-the-fly toggle for Preferences, and a "reminder" feature for novices.

    • Stevethefiddle 14:16, 4 March 2011 (UTC)
      "Which is default?"
      The default should probably be: All supported Files
    • "If so this looks like "one command doing different things" too. "
      The wording on the dialogue is just an example. It could be:
      Do you wish to import the file instead?
      Please use the Import Audio option.
    • "The menu item should really say "Link to WAV" (if wxMac, "Link to WAV or AIFF"),"
      I thought there was a plan to eventually extend On Demand to other file formats?
    • "How does this scheme cope with users who use File > Open or drag files in? "
      In my opinion dragging should default to Import as it is safer. There could be a Preference setting if people think that it is worthwhile, but the default should be to Import.
      File > Open should only give the option to open Projects. As we are constantly educating novice users, Audacity does not open audio files for editing - unlike simple wave editors, with Audacity you cannot open an audio file, edit it and save it. This is a major source of confusion for novice users. I can't imagine any novice user realising that Open > wav file really means Open a new project and create an alias to the file that you think you are opening.
    • "My own typical workflow is to drag in aliased WAVs, so I would be very inconvenienced if dragging copied in. "
      Then that is a case for retaining an option in Preferences.
    • "You say "appropriate warnings could still be shown as discussed earlier." Which warnings and where?"
      There have been numerous discussions about displaying suitable warnings when using On Demand import, saving projects with dependencies, missing dependencies. first time use of On Demand, and related issues. Since this page was started some of those ideas have been implemented and others have been improved upon. I'm not saying that this proposed menu option is a panacea that replaces all warning messages - warning messages can be retained as appropriate.
    • "where is the explanation that tells user they can import WAVs much faster if they use "Link to WAV", but that "Import Audio" will be safer?"
      On Demand importing has been described as a "flagship" feature. As such I would expect it to be prominently advertised.
      When a user clicks on File > Import > they will be presented with 5 options. How does the user know what any of them are? If they don't know what they are doing and can't work out which is the appropriate function and they don't rtfm, then at least with this layout they are more likely to guess the safe option than ending up in tears.

  • Peter 23Feb10: I am a great believer in the simplicity and clarity of one command for one function, it leads to a purer UI. I will try to summarize the core of Steve's suggestions and to address Gale's objections.
  1. Import: always copies in uncompressed files (WAV and AIFF - note,AIFF is usabel in Windows too) - and copies in compressed files MP3, AAC etc. All imports are of course turned into Audacity project format.
  2. Link: will only Link to uncompressed files. I am somewhat agnostic as to whether Steve's suggested message of offering an import if the user tries to Link to compressed files - or an alternative message that just blocks the user from linking to a compressed file with an error message that just tells them to use the import command instead. I have a slight preference for the latter on grounds of purity.
  3. Open: The behaviour of this command should be changed so that all it can ever do is open an Audacity project. It should not be possible to "open" a WAV/AIFF file which in current Audacity behaviour is actually an Open Audacity project coupled with an implied and hidden "import compressed audio" command. This has very recently been raised by Steve on the forum (see http://forum.audacityteam.org/viewtopic.php?f=20&t=26504 ) where it has already attracted several votes in favour. I support this on grounds of command purity.
    • Gale: However this makes a two step process to "open" audio files into a new project window, a common task. I think the rationale for making this one step is that (to the user) it's rather like Open in a word processor, which doesn't open a new project window, but opens the new document in a new self-contained tab (we could equally have tabs instead of new project windows). This is why it is "unexpected" that "Open" opens a new window. Plus, almost any well behaved app will have Open for opening generic file formats, which is why many users go for it rather than Import.

      So I'm -1 on restricting Open to .aup on usability grounds and I think "what open does" is a separate issue that should go on Proposal Menu Reorganisation. If we don't change Open behaviour, we need to know whether in your scheme Open copies in or reads directly. But FWIW, I think having a separate submenu for "Project actions" and "Open" does not handle .aup files might be better. It might help stop people opening the .au files from their project that way. If anything, I would get rid of "Import". It clearly isn't understood by novices. Where and how audio files "open" should be decided in an Open menu.

    • Peter 24Feb10: I'd obviously prefer to restrict Open to native .aup format only - but I can see your reasoning. So if we did not restrict Open, then I would prefer it to adopt the "safer" Import - this way it would have the same action for both compressed and uncompressed files.
  • File > Open: this would then only Open Audacity projects and not WAV/AIFF audio files nor uncompressed audio
    • Bill 07Dec10: +1 Rename to "File > Open Project...". Users can curretly use this to "open" a WAV file, leading to the conclusion that Audacity is a WAV editor. When they then "Save", what they see doesn't make sense given that assumption.
  • Dragging audio files in: this would invoke an Import (i.e. "safer" copy in) for compressed and uncompressed audio. It should not be a mechanism to open an Audacity project by dragging in an aup file. This obviously has the disadvantage of disrupting Gale's current workflow - but has the advantage of command purity. I am pretty sure that most users think that they are copying a file in rather than just linking to it when they do drag-and-drop.
    • Gale: Dragging isn't an explicit command, which is why we probably still need a preference for copy/read directly. In fact some us expect that dragging in an .aup would simply open the project in a new window, not give an "unknown format" error as now! Most project-based apps support dragging in the native project file.
    • Peter 24Feb10: I have added a note to the alternative proposal to retain the preferences setting to control the behaviour of drag-and-drop (it would obviously be redundant as far as the Import/Link commands were concerned)
  • Advice & warnings: On first use of of Import, the user should be displayed the advice message that informs them of the benefits (and risks) of Linking to alias files - this message should have an option to not be shown again if required. On first use of Link, the user should be displayed the advice message that informs the of the safer nature of import and warning them that this takes longer - as well as warning them of the dependency risks of linking to alias files - this message too should have an option to not be shown again if required.
    • Gale: So you think there should be different warnings for "link" and "import", and in your scheme you get the "import" warning for dragging in? Isn't better design to tell someone of the consequences of doing something before they do it, rather than make their action take a specific consequence (copy in or read directly) and then tell them the consequences of the action we forced them to take?
    • Peter 24Feb10:Since I have now revised my scheme to offer both behaviours for dragging in (dependent on the Preferences "safer"/"faster" option) the message displayed would depend on the mode the user (or the default) has set.