Re: [Audacity-devel] Checklist clean up
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2007-08-28 03:55:25
|
| From James Crook <cr...@in...> | Sun, 26 Aug 2007 14:18:25 +0100 | Subject: [Audacity-devel] Checklist clean up | > * Reduce 'greying out' of effects confusion by select-all-when none | > for effects.... | Are we now happy enough with what is in CVS? It doesn't do this, but it | does tell you to select the audio. Sorry I have not commented on this before now. I'd still have preferred select-all-when-none, for three reasons: 1) Select-all-when-none is useful for its own sake as it is a huge time saver not to have to "select all" if you frequently want to apply effects or other commands to all audio on screen, as users often do want to do. 2) I am sure all of us will sometimes try to run an effect in a rush, forgetting we have not selected audio (I do it often myself) and frankly the warning will soon become very irritating IMHO. 3) We have the confusion of "active greying" of menus. Additionally we have a situation where in some menu dropdowns, items requiring an audio selection are greyed out where no audio is selected, but not in others. Also we sometimes mix "active greying" and "normal greying" in the same menu, and Some inconsistenices: * Edit Menu: We have "grey out Split New when no track selected" as an Aim-to, but also need Split to be greyed out when no audio tracks are open. I've added this as an Aim-to. All else in the Edit menu except Split and Split new that requires audio selection is greyed out when none is selected, but users do have regular confusion with being unable to cut, copy, silence and delete when an audio track is on screen but no audio is selected. * Tracks Menu: Here, Resample and Quick Mix are not greyed even though they depend on an audio selection, and even though they wil not rarely be used by the novice users who are one part of the problem. One oddity not directly related: Arrow keys and ENTER give "disallowed" error when no track is on screen. As you can use spacebar and other hotkeys without this error without tracks on screen, I am not sure we need the error thrown for this. We did not go for select-all-when-none as David proposed a "smart selection" so that if a track is selected with no time range you get all the audio of that track selected, and if a time range is selected without tracks selected, you get that time range selected for all tracks. I still don't like that because: 1) that makes assumptions about what audio you were intending to select when you forgot to do so just as select-all-when-none does, while not being so generally useful. 2) this will be relatively difficult to explain what is actually the basis of the selection, and novices who were expecting "select all" will remain confused with what happens just as they are in 1.2.x when nothing happens. David then counter-proposed the idea where if no tracks and/or time range is selected, then an effect is applied to all tracks and/or all time, but the selection on the interface is not affected. If this means select-all-when-none applies, but without actually selecting audio, I can live with that as a far better solution than the current active greying. It is not so transparent to the sighted user, but David cited the benefits that the user doesn't have to unselect everything after applying an effect (which often the user would otherwise have to do), and that a user of a screen reader doesn't have to remember that everything has been silently selected. Plus, we still get the time saving of not having to select all when that's what you want to do. BTW Goldwave has an alternative solution which is hard to get used to after Audacity but seems a viable alternative: by default, all audio is selected, not none, so that when you drag out a selection area, everything is unselected except the selection area. Anyway, is it possible to go forward with what I'm proposing in the above paragraph, and stop all the active greying, or is there any practical difficulty with Audacity applying processing to all audio when it all of it isn't (visibly) selected? | > * Change dialog when you open a 1.2 project. It shouldn't discourage | > users from doing it, it should just tell them that this will change | > the project to a 1.4 project file that can't be opened by 1.2. | > Current text under discussion on audacity-devel | This is still an issue! What text do we want for this? Though we do need to say once the .aup is opened in 1.4 that it can't be opened in 1.2, I am not sure we can do away with the "back up" warning until we are sure about the error issues opening Projects from older versions. I have not yet actually found any 1.2.6 Projects that give errors in 1.3.3 that are not genuine inconsistencies, but I have not had much time (the ones i recalled have actually had linked files moved, though I know where to...). I am sure we will get errors opening 1.x Projects unless things have improved on 1.3.2, and if it's James' view we should open these early Projects then I think we must have a back-up warning. If we still cannot find 1.2.x Projects that open improperly, or if 1.2.6 seems safe but 1.2.x before that not, we could simply not show the warning when 1.2.6 is detected. Can others help as well, by opening a few 1.2.x and earlier Projects in 1.3.3? | > Totally unsure... | > * Remove VST support | Who knows about this? I agree with Richard, it's a non-starter for Windows users without DirectX plug-in support to replace it, and we cannot do much with DX if MS support is being phased out. Complaints about limited VST support are relatively unusual compared to what I suspect are the large numbers of downloads of the Enabler, and there are so many VST plug-ins available for Windows that most of the time an alternative plug that does something similar can be found to cover for one that does not work. I've removed this from the checklist. Audacity would need several important built-in effects it lacks (e.g. de-esser, chorus, vocoder) for withdrawal of VST to be acceptable IMHO. | > * Is the screenshot menu item to be available in 1.4.0? Present in | > debug builds, absent in release? | | Dominic: You wrote the screenshot feature. Do you think absent in | release, present in debug is the correct approach? My cents is that I think it should be available in all released Beta builds, but possibly not in the Stable (unless we have time to throughly test it and fix it so that it is always on top when open). | > * Fix: Jorge's Mis-selection of sample rate as 'default' when card | > can't support file's rate.... | Who knows about this? 1.3.3 in Windows for me simply won't do other than select the Default Sample Rate as Project Rate if the sample rate of the imported file is not in the Project Rate dropdown (i.e. it's precisely the same behaviour as in 1.3.2). Jorge was actually querying that the behaviour in 1.3.3 had changed for him from 1.3.2 (i.e. when in 1.3.3 when he imports a 32 KHz file with his Default Sample Rate at 44 100 Hz and 32 KHz is not listed in the Project Rate drodpown, he does get the Project Rate changed to 32 KHz). Anyway as what Jorge sees is our intention I've annotated this checklist item with Richard's comments and now added an item to "Not Aiming for 1.4" to have a Preference to force Project Rate to Default Sample Rate irrespective of the imported file. Gale Outbound message virus free. Tested on: 8/28/2007 4:55:23 AM |