Re: [Audacity-devel] Clicktrack input string verification
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve <ste...@gm...> - 2009-09-07 17:23:52
|
As Gale said earlier, the problem that was reported on the forum probably arose from the user entering a comma as a decimal separator. Although this localisation issue with Nyquist has been / will be fixed, there was still the issue that text input was not being verified or checked in any way. Any incorrect input here would either produce an unhelpful error message from Nyquist, or even conceivably cause Audacity to lock up (if for example a very long click track duration was accidentally entered). The Click Track plug-in does not take duration from the selected track. If the plug-in has been used previously in the Audacity session, it will use the settings that were used last. When it is used for the first time in a session, it uses default values irrespective of whether a track is selected or not. The clicks/pings do not appear to be clipped. I agree with David about leaving the string-input field for "optional click track duration" as accepting one or two whole numbers, and to make that clearer on the screen. Gale's suggestion of putting "Whole numbers only" to the right of the text box sounds good to me. While it is not too bad if "3,5 2,0" in European locale and " 3.5 2.0" in UK/US locale both work for 212 seconds, as you say they just learn that spaces must separate the values. However, if only integers are allowed, then they will learn more quickly as entering a decimal will produce an "educational" error message. It avoids people getting confused as to why they get 4 seconds when they enter 2,04 thinking that they have entered 2 minutes and 4 seconds. In the last submitted attachment I have already added the text "Whole numbers must be used." to the first help screen and "Decimals are not allowed." to the error messages. So what happens now? Does someone make a decision and apply the changes to the text? If it helps I'd be happy to post an amended version once it is settled, but quite happy for someone else to do it. Steve On Mon, 2009-09-07 at 02:26 -0700, David R. Sky wrote: > Thanks Gale, I like it when people leave their responses at the top, as I > don't need to search for the actual response text. > > I'm inclined to leave the string-input field for optional click track > duration as accepting one or two whole numbers, and make that clearer on > the screen or in one of the help screens. > > And if there already exists a track, I think it's possible to select all > for that first track and Click Track can get the duration from that > without needing the user to check duration on the screen. I need to check > that this will work first. And it would also mean the user would have to > _select_ some audio like with an effect, but I suppose that's a small > thing compared with the convenience, especially if the first track isn't > particularly embedded in a time signature. > > side note to this discussion - is it my ears or what, do a lot of the > generated clicks sound like they're clipped? Could someone look > way-up-close and see whether some clicks are vertically or horizontally > clipped? - the latter meaning that the waveform has abrupt fade-in and/or > fade-out? I cringed this time when I heard it! :-S > > David > > -- > David R. Sky > http://www.shellworld.net/~davidsky/ > > > On Mon, 7 Sep 2009, Gale Andrews wrote: > > > > > Replying on top, due to the length. > > > > Thanks again, Steve (and David). I don't think > > "a) with Markus' localisation fix, use the error checking as in > > clicktrack2.ny" > > > > is bad if "3,5 2,0" in European locale and " 3.5 2.0" in > > UK/US locale both work for 212 seconds; they just learn > > that spaces must separate the values. If people are > > matching a click track to the length of an existing track, > > they may find it easier to enter decimals e.g. "2 55.5" > > for 2 minutes 55.5 seconds which they might read off the > > Timeline. > > > > Still, I say let David have the casting vote on that, also > > bearing in mind I guess a) is more work. If we go for > > b) (integers only), how about saying "whole numbers only" > > in the current space to right of the "Optional click track > > duration" text box? There isn't really room to give the > > ranges for both minutes and seconds anyway. > > > > If we go for a), we could fill the space with "View help for > > ranges". And if we go for a), we don't really need a choice of > > separator do we? > > > > > > > > Gale > > > > > > > > > > > > | From "David R. Sky" <dav...@sh...> > > | Sun, 6 Sep 2009 20:09:44 -0700 (PDT) > > | Subject: [Audacity-devel] Clicktrack input string verification > >> Oh - I read too fast too soon lol! > >> > >> Although I don't particularly like the following, there's also the option > >> to select (using a choice field) whether to use the comma or period as a > >> decimal separator. > >> > >> On Mon, 7 Sep 2009, Steve wrote: > >> > >>> On Mon, 2009-09-07 at 00:34 +0100, Gale Andrews wrote: > >>>> | From Steve <ste...@gm...> > >>>> | Sun, 06 Sep 2009 21:10:12 +0100 > >>>> | Subject: [Audacity-devel] Clicktrack input string verification > >>>>> The "Optional Click Track Duration" is not verified and generates error > >>>>> messages that are no user friendly such as: > >>>>> "Nyquist returned the value: 10" > >>>>> > >>>>> This issue was raised on the forum > >>>>> http://forum.audacityteam.org/viewtopic.php?f=16&t=12968&p=49980#p49912 > >>>>> > >>>>> Attached is an updated version that verifies this input and produces a > >>>>> meaningful error message if invalid data is entered. > >>>>> > >>>>> I also made a couple of minor grammatical alterations to the first help > >>>>> screen. > >>>> > >>>> > >>>> Hi Steve, > >>>> > >>>> Thanks for that. I suspect though he is in Italy where comma is the > >>>> decimal separator. If so then I'm not quite sure, but after Markus' > >>>> localisation fix for Nyquist in Audacity, he might find the comma > >>>> he was entering will be accepted as a decimal separator. In that > >>>> case, there would be no error even with the click track currently > >>>> in CVS. Instead the wrong length will be generated: if in UK locale > >>>> you enter "4.30" for 4 minutes, 30 seconds in "Optional Click Track > >>>> Duration", you generate 6 seconds. Entering "4.5", thinking you might > >>>> get 4.5 seconds also gives you 6 seconds. This is still the case in > >>>> clicktrack2, so I think we want to arrange it so that "." (in UK/US > >>>> locale) and "," (in European locales) is rejected and gives the error > >>>> you put in. > >>>> > >>>> Gale > >>> > >>> This had occured to me also, and that's the trouble with these darned > >>> commas, they can be used to mean anything. > >>> > >>> I think there is no elegant way of dealing with commas in this case > >>> because with a European localisation that allows commas as separators > >>> there is no way that the plug-in can know if a comma has been put in > >>> with the intention of being a decimal separator or a list separator. > >>> > >>> The two options as I see it are either: > >>> a) with Markus' localisation fix, use the error checking as in > >>> clicktrack2.ny > >>> b) disallow decimals altogether. > >>> > >>> In the case of a) with either commas or full stops (periods), > >>> 3.5 will be 3.5 seconds > >>> 3.5 2.0 will be 3.5 minutes + 2.0 seconds =212.0 seconds > >>> 3.5, 0.0 will give an error > >>> > >>> Without Markus' fix any comma will produce an error. > >>> > >>> In the case of b) > >>> This is very easy to achieve by simply removing all instances of > >>> (floatp (second m-s)) from the validation code that I added. > >>> The validation will then require two and only two whole numbers. > >>> > >>> Personally I prefer option b) as I see little reason for entering > >>> fractions of a minute or fractions of seconds as the duration gets > >>> rounded up to the next measure anyway. However I did not want to exclude > >>> decimals as they are allowed in the existing code. > >>> > >>> Disallowing decimals is probably most easily achieved by using the > >>> verification code and making it clear in the help that whole numbers > >>> (integers) are required. > >>> > >>> I've attached version2b that allows only integers. > >>> I've also adjusted the value ranges to: > >>> Seconds 0 to 3660 > >>> Minutes/Seconds to 60/59 > >>> I think it is unlikely that anyone will want a click track longer than > >>> 61 minutes. > >>> > >>> I've added the text "Whole numbers must be used." to the first help > >>> screen and "Decimals are not allowed." to the error messages. > >>> > >>> Steve > > > > > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > audacity-devel mailing list > > aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |