Re: [Audacity-devel] Deleting selection at the beginning
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
|
From: Markus M. <me...@me...> - 2004-07-05 12:33:20
|
Shane, thanks for the very interesting info concerning the UI research. I'd like to add that one should _always_ try not to mix up implementation and interface. If "silence" takes up to much space, _that_ should be fixed, not the command "silence" replaced by another command. What should be the default behaviour is another question, of course -- but I think that Audacity can already be customized enough (keybaord shortcuts etc.) so that this shouldn't matter too much. Markus Am Mon, den 05.07.2004 schrieb Shane Mueller um 14:10: > On Mon, 2004-07-05 at 10:31 +0100, Daniel James wrote: > > > > 1. Deleting a selection at the beginning of a track moves the > > > > rest of the audio back up the timeline. This is a problem with a > > > > multitrack project of course, because the tracks are then out of > > > > sync. Could this behaviour be made a preference? > > > > > > Why not use "Silence" instead of "Delete" in this case? > > > > I figure if you've got a load of blocks that you don't need, it's > > better to delete them (rather than silence them) to save disc space. > > > > To give an example - you've got a five minute track played by a live > > band with a fifteen-second violin solo near the end. During the first > > four minutes on this track, the violin player is shuffling around, > > making background noise. > > Although I don't think the silence function uses the amount of space you > might think it does (it may actually be close to nothing, and probably > no larger than a single blockfile no matter how long the silence is), > another way to get the behavior you want is to use the trim function, as > long as the part of the track you want to get rid of is at the > beginning; yet another way is to select the region you want to keep and > "Duplicate" in onto a new track. > > I'm sure we've all run into situations with software we use where the > developer takes an "I-Know-Best" attitude to feature suggestions (at > least people like me who use Gnome), offering excuses and workarounds > but not expressing interest in just fixing it. I hope this doesn't seem > like that type of situation, but the costs are not only in the extra > time it takes to add such features---they also can add complexity for > the regular user. A friend of mine has done research using an eye- > tracker to examine selection of items from pulldown menus--he showed > that menu search is a bizarre mixture between linear search (scanning > down the menu item-by-item) and random jumping around. Essentially, each > additional item you add to a menu adds roughly a constant amount of > search time for the novice user; items toward the bottom take a little > longer, but people compensate by jumping down to the bottom just in case > its down there, which might actually hurt them in the long run except > that they are probably eventually able to guess where items are in the > list; and so then it helps them. > > A useful question to ask when considering adding a new menu item is > whether the time it saves is worth the extra cost incurred every time an > item from the menu is chosen. Adding something to the edit menu could > increase selection time of things from that menu by a couple hundred ms; > if a function you introduce replaces a sequence of tasks that normally > takes more than a few seconds, that might be worthwhile, depending on > how often it is used relative to other entries in the menu. A 250 ms > cost could swamp a 5 sec savings for a user who uses that menu item less > than 5% of the times that menu is selected. I suggest that, for now, > adding a delete-in-place is not worth the cost as it can already be > accomplished a few other ways (add silence, duplicate, trim, or delete- > and-manually-align). As Dominic suggested, be on the lookout for ways to > incorporate such a function that would give us a lot of bang for the > buck. > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |