Thread: [Audacity-quality] Numerical input validation
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2013-11-21 16:25:43
|
I've been looking at bug 685 (Limited precision for Nyquist plug-in sliders) and comparing the validation of typed input with that in other effects. I've discovered there is a lot of variation. In most cases validation is against any numerical character, that is: 0 to 9, +, -, e, "." (dot) and "," (comma). Although comma can be typed, when the language setting is English the comma and any characters after the comma are ignored. I've not tested with other language settings. In Change Pitch "Frequency" control, validation is against: 0 to 9 and "." only. This control will not accept a comma as the decimal separator in any language. If we decided that it was acceptable to only allow "dot" as the decimal separator, then all effects (including Nyquist plug-ins) could be made consistent with this. Thoughts, comments? Steve |
From: Vaughan J. <va...@au...> - 2013-11-22 00:05:22
|
Most validators (where they were even used) were written over a number of years by different people, and some were even less complete, e.g., just allowing digits and punctuation. For most of that time span, wxWidgets validators were very limited, e.g., text-only or digits-only. Leland backported some more elaborate validators from wxWidgets 3.0rc1, into valnum.*, and used them in Nyquist.cpp. +1 to going through all controls and applying the most appropriate validator from the valnum classes. - V On 11/21/2013 8:25 AM, Steve the Fiddle wrote: > I've been looking at bug 685 (Limited precision for Nyquist plug-in > sliders) and comparing the validation of typed input with that in > other effects. I've discovered there is a lot of variation. > > In most cases validation is against any numerical character, that is: > 0 to 9, +, -, e, "." (dot) and "," (comma). > Although comma can be typed, when the language setting is English the > comma and any characters after the comma are ignored. I've not tested > with other language settings. > > In Change Pitch "Frequency" control, validation is against: > 0 to 9 and "." only. > This control will not accept a comma as the decimal separator in any language. > > If we decided that it was acceptable to only allow "dot" as the > decimal separator, then all effects (including Nyquist plug-ins) could > be made consistent with this. > > Thoughts, comments? > > Steve > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Steve t. F. <ste...@gm...> - 2013-11-22 15:02:44
|
On 22 November 2013 00:05, Vaughan Johnson <va...@au...> wrote: > Most validators (where they were even used) were written over a number > of years by different people, and some were even less complete, e.g., > just allowing digits and punctuation. For most of that time span, > wxWidgets validators were very limited, e.g., text-only or digits-only. > > Leland backported some more elaborate validators from wxWidgets 3.0rc1, > into valnum.*, and used them in Nyquist.cpp. > > +1 to going through all controls and applying the most appropriate > validator from the valnum classes. The main problem that we have with using the new validator is that wxFloatingPointValidator limits the precision to a specified number of decimal places. For some Nyquist plug-ins (such as "Tempo" in Click Track) this is clearly a regression (bug 685). All Nyquist plug-ins use the same widgets and the same validators, and the only way that I can see to restore "unlimited" precision for typed values is to revert back to the old wxFILTER_NUMERIC validator, but then we lose validation of the decimal separator character. I don't see any way to allow unlimited precision for typed values while using the new wxFloatingPointValidator (though that could just be down to my lack of experience), There are also accessibility issues due to range validation with the new validators (bug 681). Again this could easily be resolved for Nyquist plug-ins by reverting to old validation methods, but again we lose the benefits of the new validators. I suppose the real question here is, can bugs 681 and 685 be fixed while still using the new validators? (I have a patch on bugzilla for bug 681 but Gale tells me that it does not work correctly on Windows). If these bugs can be fixed (cross platform) then I guess that we would want to roll this out across other effects? Steve > - V > > > On 11/21/2013 8:25 AM, Steve the Fiddle wrote: >> I've been looking at bug 685 (Limited precision for Nyquist plug-in >> sliders) and comparing the validation of typed input with that in >> other effects. I've discovered there is a lot of variation. >> >> In most cases validation is against any numerical character, that is: >> 0 to 9, +, -, e, "." (dot) and "," (comma). >> Although comma can be typed, when the language setting is English the >> comma and any characters after the comma are ignored. I've not tested >> with other language settings. >> >> In Change Pitch "Frequency" control, validation is against: >> 0 to 9 and "." only. >> This control will not accept a comma as the decimal separator in any language. >> >> If we decided that it was acceptable to only allow "dot" as the >> decimal separator, then all effects (including Nyquist plug-ins) could >> be made consistent with this. >> >> Thoughts, comments? >> >> Steve >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-11-23 04:25:43
|
On 11/22/2013 7:02 AM, Steve the Fiddle wrote: > On 22 November 2013 00:05, Vaughan Johnson <va...@au...> wrote: >> Most validators (where they were even used) were written over a number >> of years by different people, and some were even less complete, e.g., >> just allowing digits and punctuation. For most of that time span, >> wxWidgets validators were very limited, e.g., text-only or digits-only. >> >> Leland backported some more elaborate validators from wxWidgets 3.0rc1, >> into valnum.*, and used them in Nyquist.cpp. >> >> +1 to going through all controls and applying the most appropriate >> validator from the valnum classes. > > The main problem that we have with using the new validator is that > wxFloatingPointValidator limits the precision to a specified number of > decimal places. For some Nyquist plug-ins (such as "Tempo" in Click > Track) this is clearly a regression (bug 685). > > All Nyquist plug-ins use the same widgets and the same validators, and > the only way that I can see to restore "unlimited" precision for typed > values is to revert back to the old wxFILTER_NUMERIC validator, but > then we lose validation of the decimal separator character. > I don't see any way to allow unlimited precision for typed values > while using the new wxFloatingPointValidator (though that could just > be down to my lack of experience), > > There are also accessibility issues due to range validation with the > new validators (bug 681). Again this could easily be resolved for > Nyquist plug-ins by reverting to old validation methods, but again we > lose the benefits of the new validators. Aren't they overall better than what we have? Implement them, then override those classes to do what we want? Write our own and ditch those? I think the options are clear, and we want to be consistent within Audacity. - V > > I suppose the real question here is, can bugs 681 and 685 be fixed > while still using the new validators? (I have a patch on bugzilla for > bug 681 but Gale tells me that it does not work correctly on Windows). > If these bugs can be fixed (cross platform) then I guess that we would > want to roll this out across other effects? > > Steve > > >> - V >> >> >> On 11/21/2013 8:25 AM, Steve the Fiddle wrote: >>> I've been looking at bug 685 (Limited precision for Nyquist plug-in >>> sliders) and comparing the validation of typed input with that in >>> other effects. I've discovered there is a lot of variation. >>> >>> In most cases validation is against any numerical character, that is: >>> 0 to 9, +, -, e, "." (dot) and "," (comma). >>> Although comma can be typed, when the language setting is English the >>> comma and any characters after the comma are ignored. I've not tested >>> with other language settings. >>> >>> In Change Pitch "Frequency" control, validation is against: >>> 0 to 9 and "." only. >>> This control will not accept a comma as the decimal separator in any language. >>> >>> If we decided that it was acceptable to only allow "dot" as the >>> decimal separator, then all effects (including Nyquist plug-ins) could >>> be made consistent with this. >>> >>> Thoughts, comments? >>> >>> Steve >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: David B. <drb...@go...> - 2013-11-23 17:20:06
|
On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle <ste...@gm...>wrote: > > The main problem that we have with using the new validator is that > wxFloatingPointValidator limits the precision to a specified number of > decimal places. For some Nyquist plug-ins (such as "Tempo" in Click > Track) this is clearly a regression (bug 685). > Just out of curiosity, why would someone need to specify the number of beats per min to more than two decimal places? If they do need to do this, how many decimal places would they need? David. |
From: Vaughan J. <va...@au...> - 2013-11-24 02:47:21
|
On 11/23/2013 9:19 AM, David Bailes wrote: > On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle > <ste...@gm... <mailto:ste...@gm...>> wrote: > > > The main problem that we have with using the new validator is that > wxFloatingPointValidator limits the precision to a specified number of > decimal places. I don't think so. There are two constructors for the wxFloatingPointValidator class. See valnum.h. One of them specifies limited precision, per comment "// Ctor specifying an explicit precision." The other says "// Ctor using implicit (maximal) precision for this type." So maybe the wrong choice of constructor was made in Nyquist.cpp, but it should be an easy fix. And I'm +1 on using maximal precision for the global change. >For some Nyquist plug-ins (such as "Tempo" in Click > Track) this is clearly a regression (bug 685). Okay, thanks. I think this can be fixed by using the other constructor. > > > Just out of curiosity, why would someone need to specify the number of > beats per min to more than two decimal places? If they do need to do > this, how many decimal places would they need? Right. So for some cases, we might want to specify the precision, and choose the other wxFloatingPointValidator constructor. The point is that these new validators are much better than previously available. And they can be overridden, to provide specific functionality we want. - V |
From: Steve t. F. <ste...@gm...> - 2013-11-24 03:48:40
|
On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: > On 11/23/2013 9:19 AM, David Bailes wrote: >> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >> <ste...@gm... <mailto:ste...@gm...>> wrote: >> >> >> The main problem that we have with using the new validator is that >> wxFloatingPointValidator limits the precision to a specified number of >> decimal places. > > I don't think so. There are two constructors for the > wxFloatingPointValidator class. See valnum.h. > > One of them specifies limited precision, per comment "// Ctor specifying > an explicit precision." > > The other says "// Ctor using implicit (maximal) precision for this > type." So maybe the wrong choice of constructor was made in Nyquist.cpp, > but it should be an easy fix. And I'm +1 on using maximal precision for > the global change. I have already tried that. It works, but then the number is displayed with 15 decimal places, which is not really what we want and I don't know how to stop that from happening. Perhaps someone else could take a look. > > >>For some Nyquist plug-ins (such as "Tempo" in Click >> Track) this is clearly a regression (bug 685). > > Okay, thanks. I think this can be fixed by using the other constructor. As above, we don't really want the default tempo displayed as 120.000000000000000. >> >> >> Just out of curiosity, why would someone need to specify the number of >> beats per min to more than two decimal places? If they do need to do >> this, how many decimal places would they need? > > Right. So for some cases, we might want to specify the precision, and > choose the other wxFloatingPointValidator constructor. > > The point is that these new validators are much better than previously > available. And they can be overridden, to provide specific functionality > we want. Yes, they are clearly much better, but how do we then restrict the number of zeros shown? Steve > > - V |
From: Vaughan J. <va...@au...> - 2013-11-25 03:07:02
|
On 11/23/2013 7:48 PM, Steve the Fiddle wrote: > On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >> On 11/23/2013 9:19 AM, David Bailes wrote: >>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>> >>> >>> The main problem that we have with using the new validator is that >>> wxFloatingPointValidator limits the precision to a specified number of >>> decimal places. >> >> I don't think so. There are two constructors for the >> wxFloatingPointValidator class. See valnum.h. >> >> One of them specifies limited precision, per comment "// Ctor specifying >> an explicit precision." >> >> The other says "// Ctor using implicit (maximal) precision for this >> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >> but it should be an easy fix. And I'm +1 on using maximal precision for >> the global change. > > I have already tried that. It works, but then the number is displayed > with 15 decimal places, which is not really what we want So there's a little conflict here, between being able to enter very high precision and being able to see what's been entered without scrolling the text. Along the lines of what David asked, can we decide on a sufficiently high precision for each effect? And if some need maximal precision, live with the current display issue, until we override that behavior? Better than what we currently have. >and I don't > know how to stop that from happening. It's in the code, so it can be figured out. I don't have time. >Perhaps someone else could take > a look. > > >> >> >>> For some Nyquist plug-ins (such as "Tempo" in Click >>> Track) this is clearly a regression (bug 685). >> >> Okay, thanks. I think this can be fixed by using the other constructor. > > As above, we don't really want the default tempo displayed as > 120.000000000000000. So are you against the width of the control, or the integer values, where it shows all those unnecessary zeroes? On non-integer values, for high precision, shouldn't it show the actual precision? Since we're using a backport of the wxWidgets valnum.c, we can just fix it, I expect. Probably just a matter of a change of one or two formatting specs. - V > >>> >>> >>> Just out of curiosity, why would someone need to specify the number of >>> beats per min to more than two decimal places? If they do need to do >>> this, how many decimal places would they need? >> >> Right. So for some cases, we might want to specify the precision, and >> choose the other wxFloatingPointValidator constructor. >> >> The point is that these new validators are much better than previously >> available. And they can be overridden, to provide specific functionality >> we want. > > Yes, they are clearly much better, but how do we then restrict the > number of zeros shown? > > Steve > > >> >> - V > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Gale A. <ga...@au...> - 2013-11-25 09:39:52
|
| From Vaughan Johnson <va...@au...> | Sun, 24 Nov 2013 19:06:51 -0800 | Subject: [Audacity-quality] Numerical input validation > On 11/23/2013 7:48 PM, Steve the Fiddle wrote: > > On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: > >> On 11/23/2013 9:19 AM, David Bailes wrote: > >>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle > >>> <ste...@gm... <mailto:ste...@gm...>> wrote: > >>> > >>> > >>> The main problem that we have with using the new validator is that > >>> wxFloatingPointValidator limits the precision to a specified number of > >>> decimal places. > >> > >> I don't think so. There are two constructors for the > >> wxFloatingPointValidator class. See valnum.h. > >> > >> One of them specifies limited precision, per comment "// Ctor specifying > >> an explicit precision." > >> > >> The other says "// Ctor using implicit (maximal) precision for this > >> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, > >> but it should be an easy fix. And I'm +1 on using maximal precision for > >> the global change. > > > > I have already tried that. It works, but then the number is displayed > > with 15 decimal places, which is not really what we want > > So there's a little conflict here, between being able to enter very high > precision and being able to see what's been entered without scrolling > the text. > > Along the lines of what David asked, can we decide on a sufficiently > high precision for each effect? And if some need maximal precision, live > with the current display issue, until we override that behavior? Better > than what we currently have. [...] > >>> For some Nyquist plug-ins (such as "Tempo" in Click > >>> Track) this is clearly a regression (bug 685). > >> > >> Okay, thanks. I think this can be fixed by using the other constructor. > > > > As above, we don't really want the default tempo displayed as > > 120.000000000000000. > > So are you against the width of the control, or the integer values, > where it shows all those unnecessary zeroes? On non-integer values, for > high precision, shouldn't it show the actual precision? +1 in principle to it showing the actual precision for non-integer values. But I am guessing that if the default tempo was 120.000000000000000 and you tabbed into that, the selected text would only show "0000000" give or take a digit because the selection would auto scroll to the end. If that's a concern (I think it is) then we can't show more than six or seven numbers plus the decimal separator somewhere amongst them for the default value. Gale > Since we're using a backport of the wxWidgets valnum.c, we can just fix > it, I expect. Probably just a matter of a change of one or two > formatting specs. > > > - V > > > > > >>> > >>> > >>> Just out of curiosity, why would someone need to specify the number of > >>> beats per min to more than two decimal places? If they do need to do > >>> this, how many decimal places would they need? > >> > >> Right. So for some cases, we might want to specify the precision, and > >> choose the other wxFloatingPointValidator constructor. > >> > >> The point is that these new validators are much better than previously > >> available. And they can be overridden, to provide specific functionality > >> we want. > > > > Yes, they are clearly much better, but how do we then restrict the > > number of zeros shown? > > > > Steve > > > > > >> > >> - V > > > > ------------------------------------------------------------------------------ > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech innovation. > > Intel(R) Software Adrenaline delivers strategic insight and game-changing > > conversations that shape the rapidly evolving mobile landscape. Sign up now. > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Audacity-quality mailing list > > Aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-11-25 19:36:16
|
On 11/25/2013 1:39 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Sun, 24 Nov 2013 19:06:51 -0800 > | Subject: [Audacity-quality] Numerical input validation >> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>> >>>>> >>>>> The main problem that we have with using the new validator is that >>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>> decimal places. >>>> >>>> I don't think so. There are two constructors for the >>>> wxFloatingPointValidator class. See valnum.h. >>>> >>>> One of them specifies limited precision, per comment "// Ctor specifying >>>> an explicit precision." >>>> >>>> The other says "// Ctor using implicit (maximal) precision for this >>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>> the global change. >>> >>> I have already tried that. It works, but then the number is displayed >>> with 15 decimal places, which is not really what we want >> >> So there's a little conflict here, between being able to enter very high >> precision and being able to see what's been entered without scrolling >> the text. >> >> Along the lines of what David asked, can we decide on a sufficiently >> high precision for each effect? And if some need maximal precision, live >> with the current display issue, until we override that behavior? Better >> than what we currently have. > [...] >>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>> Track) this is clearly a regression (bug 685). >>>> >>>> Okay, thanks. I think this can be fixed by using the other constructor. >>> >>> As above, we don't really want the default tempo displayed as >>> 120.000000000000000. >> >> So are you against the width of the control, or the integer values, >> where it shows all those unnecessary zeroes? On non-integer values, for >> high precision, shouldn't it show the actual precision? > > +1 in principle to it showing the actual precision for non-integer > values. > > But I am guessing that if the default tempo was 120.000000000000000 There's no "default tempo". > and you tabbed into that, the selected text would only show > "0000000" give or take a digit because the selection would auto > scroll to the end. ? Clearly, we'd need to make the control wider. - V > > If that's a concern (I think it is) then we can't show more than six > or seven numbers plus the decimal separator somewhere amongst > them for the default value. > > > > > Gale > > >> Since we're using a backport of the wxWidgets valnum.c, we can just fix >> it, I expect. Probably just a matter of a change of one or two >> formatting specs. >> >> >> - V >> >> >>> >>>>> >>>>> >>>>> Just out of curiosity, why would someone need to specify the number of >>>>> beats per min to more than two decimal places? If they do need to do >>>>> this, how many decimal places would they need? >>>> >>>> Right. So for some cases, we might want to specify the precision, and >>>> choose the other wxFloatingPointValidator constructor. >>>> >>>> The point is that these new validators are much better than previously >>>> available. And they can be overridden, to provide specific functionality >>>> we want. >>> >>> Yes, they are clearly much better, but how do we then restrict the >>> number of zeros shown? >>> >>> Steve >>> >>> >>>> >>>> - V >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Gale A. <ga...@au...> - 2013-11-26 09:16:13
|
| From Vaughan Johnson <va...@au...> | Mon, 25 Nov 2013 11:36:03 -0800 | Subject: [Audacity-quality] Numerical input validation > On 11/25/2013 1:39 AM, Gale Andrews wrote: > > > > | From Vaughan Johnson <va...@au...> > > | Sun, 24 Nov 2013 19:06:51 -0800 > > | Subject: [Audacity-quality] Numerical input validation > >> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: > >>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: > >>>> On 11/23/2013 9:19 AM, David Bailes wrote: > >>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle > >>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: > >>>>> > >>>>> > >>>>> The main problem that we have with using the new validator is that > >>>>> wxFloatingPointValidator limits the precision to a specified number of > >>>>> decimal places. > >>>> > >>>> I don't think so. There are two constructors for the > >>>> wxFloatingPointValidator class. See valnum.h. > >>>> > >>>> One of them specifies limited precision, per comment "// Ctor specifying > >>>> an explicit precision." > >>>> > >>>> The other says "// Ctor using implicit (maximal) precision for this > >>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, > >>>> but it should be an easy fix. And I'm +1 on using maximal precision for > >>>> the global change. > >>> > >>> I have already tried that. It works, but then the number is displayed > >>> with 15 decimal places, which is not really what we want > >> > >> So there's a little conflict here, between being able to enter very high > >> precision and being able to see what's been entered without scrolling > >> the text. > >> > >> Along the lines of what David asked, can we decide on a sufficiently > >> high precision for each effect? And if some need maximal precision, live > >> with the current display issue, until we override that behavior? Better > >> than what we currently have. > > [...] > >>>>> For some Nyquist plug-ins (such as "Tempo" in Click > >>>>> Track) this is clearly a regression (bug 685). > >>>> > >>>> Okay, thanks. I think this can be fixed by using the other constructor. > >>> > >>> As above, we don't really want the default tempo displayed as > >>> 120.000000000000000. > >> > >> So are you against the width of the control, or the integer values, > >> where it shows all those unnecessary zeroes? On non-integer values, for > >> high precision, shouldn't it show the actual precision? > > > > +1 in principle to it showing the actual precision for non-integer > > values. > > > > But I am guessing that if the default tempo was 120.000000000000000 > > There's no "default tempo". By "default tempo" I mean the value you see for "Tempo [beats per minute]" in Click Track when you first open it in an Audacity session. > > and you tabbed into that, the selected text would only show > > "0000000" give or take a digit because the selection would auto > > scroll to the end. > > ? Clearly, we'd need to make the control wider. Fine, if we can. Gale > > If that's a concern (I think it is) then we can't show more than six > > or seven numbers plus the decimal separator somewhere amongst > > them for the default value. > > > > > > > > > > Gale > > > > > >> Since we're using a backport of the wxWidgets valnum.c, we can just fix > >> it, I expect. Probably just a matter of a change of one or two > >> formatting specs. > >> > >> > >> - V > >> > >> > >>> > >>>>> > >>>>> > >>>>> Just out of curiosity, why would someone need to specify the number of > >>>>> beats per min to more than two decimal places? If they do need to do > >>>>> this, how many decimal places would they need? > >>>> > >>>> Right. So for some cases, we might want to specify the precision, and > >>>> choose the other wxFloatingPointValidator constructor. > >>>> > >>>> The point is that these new validators are much better than previously > >>>> available. And they can be overridden, to provide specific functionality > >>>> we want. > >>> > >>> Yes, they are clearly much better, but how do we then restrict the > >>> number of zeros shown? > >>> > >>> Steve > >>> > >>> > >>>> > >>>> - V > >>> > >>> ------------------------------------------------------------------------------ > >>> Shape the Mobile Experience: Free Subscription > >>> Software experts and developers: Be at the forefront of tech innovation. > >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing > >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. > >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >>> _______________________________________________ > >>> Audacity-quality mailing list > >>> Aud...@li... > >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality > >>> > >> > >> ------------------------------------------------------------------------------ > >> Shape the Mobile Experience: Free Subscription > >> Software experts and developers: Be at the forefront of tech innovation. > >> Intel(R) Software Adrenaline delivers strategic insight and game-changing > >> conversations that shape the rapidly evolving mobile landscape. Sign up now. > >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Audacity-quality mailing list > >> Aud...@li... > >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > > > > > ------------------------------------------------------------------------------ > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech innovation. > > Intel(R) Software Adrenaline delivers strategic insight and game-changing > > conversations that shape the rapidly evolving mobile landscape. Sign up now. > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Audacity-quality mailing list > > Aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-11-27 06:02:50
|
On 11/26/2013 1:15 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Mon, 25 Nov 2013 11:36:03 -0800 > | Subject: [Audacity-quality] Numerical input validation >> On 11/25/2013 1:39 AM, Gale Andrews wrote: >>> >>> | From Vaughan Johnson <va...@au...> >>> | Sun, 24 Nov 2013 19:06:51 -0800 >>> | Subject: [Audacity-quality] Numerical input validation >>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>>> >>>>>>> >>>>>>> The main problem that we have with using the new validator is that >>>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>>> decimal places. >>>>>> >>>>>> I don't think so. There are two constructors for the >>>>>> wxFloatingPointValidator class. See valnum.h. >>>>>> >>>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>>> an explicit precision." >>>>>> >>>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>>> the global change. >>>>> >>>>> I have already tried that. It works, but then the number is displayed >>>>> with 15 decimal places, which is not really what we want >>>> >>>> So there's a little conflict here, between being able to enter very high >>>> precision and being able to see what's been entered without scrolling >>>> the text. >>>> >>>> Along the lines of what David asked, can we decide on a sufficiently >>>> high precision for each effect? And if some need maximal precision, live >>>> with the current display issue, until we override that behavior? Better >>>> than what we currently have. >>> [...] >>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>>> Track) this is clearly a regression (bug 685). >>>>>> >>>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>>> >>>>> As above, we don't really want the default tempo displayed as >>>>> 120.000000000000000. >>>> >>>> So are you against the width of the control, or the integer values, >>>> where it shows all those unnecessary zeroes? On non-integer values, for >>>> high precision, shouldn't it show the actual precision? >>> >>> +1 in principle to it showing the actual precision for non-integer >>> values. >>> >>> But I am guessing that if the default tempo was 120.000000000000000 >> >> There's no "default tempo". > > By "default tempo" I mean the value you see for "Tempo [beats per > minute]" in Click Track when you first open it in an Audacity session. It's blank when I open it with reset prefs. So I'm guessing that 'first open' is actually not 'first'. > > >>> and you tabbed into that, the selected text would only show >>> "0000000" give or take a digit because the selection would auto >>> scroll to the end. >> >> ? Clearly, we'd need to make the control wider. > > Fine, if we can. Of course we can, it's software. - V > > > > Gale > > >>> If that's a concern (I think it is) then we can't show more than six >>> or seven numbers plus the decimal separator somewhere amongst >>> them for the default value. >>> >>> >>> >>> >>> Gale >>> >>> >>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>>> it, I expect. Probably just a matter of a change of one or two >>>> formatting specs. >>>> >>>> >>>> - V >>>> >>>> >>>>> >>>>>>> >>>>>>> >>>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>>> beats per min to more than two decimal places? If they do need to do >>>>>>> this, how many decimal places would they need? >>>>>> >>>>>> Right. So for some cases, we might want to specify the precision, and >>>>>> choose the other wxFloatingPointValidator constructor. >>>>>> >>>>>> The point is that these new validators are much better than previously >>>>>> available. And they can be overridden, to provide specific functionality >>>>>> we want. >>>>> >>>>> Yes, they are clearly much better, but how do we then restrict the >>>>> number of zeros shown? >>>>> >>>>> Steve >>>>> >>>>> >>>>>> >>>>>> - V >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Audacity-quality mailing list >>>>> Aud...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Audacity-quality mailing list >>>> Aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Gale A. <ga...@au...> - 2013-12-02 12:13:40
|
| From Vaughan Johnson <va...@au...> | Tue, 26 Nov 2013 22:02:37 -0800 | Subject: [Audacity-quality] Numerical input validation > On 11/26/2013 1:15 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > > | Mon, 25 Nov 2013 11:36:03 -0800 > > | Subject: [Audacity-quality] Numerical input validation > >> On 11/25/2013 1:39 AM, Gale Andrews wrote: > >>> > >>> | From Vaughan Johnson <va...@au...> > >>> | Sun, 24 Nov 2013 19:06:51 -0800 > >>> | Subject: [Audacity-quality] Numerical input validation > >>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: > >>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: > >>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: > >>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle > >>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> The main problem that we have with using the new validator is that > >>>>>>> wxFloatingPointValidator limits the precision to a specified number of > >>>>>>> decimal places. > >>>>>> > >>>>>> I don't think so. There are two constructors for the > >>>>>> wxFloatingPointValidator class. See valnum.h. > >>>>>> > >>>>>> One of them specifies limited precision, per comment "// Ctor specifying > >>>>>> an explicit precision." > >>>>>> > >>>>>> The other says "// Ctor using implicit (maximal) precision for this > >>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, > >>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for > >>>>>> the global change. > >>>>> > >>>>> I have already tried that. It works, but then the number is displayed > >>>>> with 15 decimal places, which is not really what we want > >>>> > >>>> So there's a little conflict here, between being able to enter very high > >>>> precision and being able to see what's been entered without scrolling > >>>> the text. > >>>> > >>>> Along the lines of what David asked, can we decide on a sufficiently > >>>> high precision for each effect? And if some need maximal precision, live > >>>> with the current display issue, until we override that behavior? Better > >>>> than what we currently have. > >>> [...] > >>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click > >>>>>>> Track) this is clearly a regression (bug 685). > >>>>>> > >>>>>> Okay, thanks. I think this can be fixed by using the other constructor. > >>>>> > >>>>> As above, we don't really want the default tempo displayed as > >>>>> 120.000000000000000. > >>>> > >>>> So are you against the width of the control, or the integer values, > >>>> where it shows all those unnecessary zeroes? On non-integer values, for > >>>> high precision, shouldn't it show the actual precision? > >>> > >>> +1 in principle to it showing the actual precision for non-integer > >>> values. > >>> > >>> But I am guessing that if the default tempo was 120.000000000000000 > >> > >> There's no "default tempo". > > > > By "default tempo" I mean the value you see for "Tempo [beats per > > minute]" in Click Track when you first open it in an Audacity session. > > It's blank when I open it with reset prefs. So I'm guessing that 'first > open' is actually not 'first'. I really cannot understand that, Vaughan. Nyquist plug-ins don't remember their settings after exit of Audacity, so after launch of Audacity (initialized .cfg or not) then launching Click Track, the slider widgets should always have populated text boxes with these values: http://manual.audacityteam.org/m/images/0/09/ClickTrackGenerator_dialog_basic7.png . Gale > >>> and you tabbed into that, the selected text would only show > >>> "0000000" give or take a digit because the selection would auto > >>> scroll to the end. > >> > >> ? Clearly, we'd need to make the control wider. > > > > Fine, if we can. > > Of course we can, it's software. > > - V > > > > > > > > > > Gale > > > > > >>> If that's a concern (I think it is) then we can't show more than six > >>> or seven numbers plus the decimal separator somewhere amongst > >>> them for the default value. > >>> > >>> > >>> > >>> > >>> Gale > >>> > >>> > >>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix > >>>> it, I expect. Probably just a matter of a change of one or two > >>>> formatting specs. > >>>> > >>>> > >>>> - V > >>>> > >>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> Just out of curiosity, why would someone need to specify the number of > >>>>>>> beats per min to more than two decimal places? If they do need to do > >>>>>>> this, how many decimal places would they need? > >>>>>> > >>>>>> Right. So for some cases, we might want to specify the precision, and > >>>>>> choose the other wxFloatingPointValidator constructor. > >>>>>> > >>>>>> The point is that these new validators are much better than previously > >>>>>> available. And they can be overridden, to provide specific functionality > >>>>>> we want. > >>>>> > >>>>> Yes, they are clearly much better, but how do we then restrict the > >>>>> number of zeros shown? > >>>>> > >>>>> Steve > >>>>> > >>>>> > >>>>>> > >>>>>> - V |
From: Vaughan J. <va...@au...> - 2013-12-04 19:14:26
|
On 12/2/2013 4:13 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Tue, 26 Nov 2013 22:02:37 -0800 > | Subject: [Audacity-quality] Numerical input validation >> On 11/26/2013 1:15 AM, Gale Andrews wrote: >>> | From Vaughan Johnson <va...@au...> >>> | Mon, 25 Nov 2013 11:36:03 -0800 >>> | Subject: [Audacity-quality] Numerical input validation >>>> On 11/25/2013 1:39 AM, Gale Andrews wrote: >>>>> >>>>> | From Vaughan Johnson <va...@au...> >>>>> | Sun, 24 Nov 2013 19:06:51 -0800 >>>>> | Subject: [Audacity-quality] Numerical input validation >>>>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> The main problem that we have with using the new validator is that >>>>>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>>>>> decimal places. >>>>>>>> >>>>>>>> I don't think so. There are two constructors for the >>>>>>>> wxFloatingPointValidator class. See valnum.h. >>>>>>>> >>>>>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>>>>> an explicit precision." >>>>>>>> >>>>>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>>>>> the global change. >>>>>>> >>>>>>> I have already tried that. It works, but then the number is displayed >>>>>>> with 15 decimal places, which is not really what we want >>>>>> >>>>>> So there's a little conflict here, between being able to enter very high >>>>>> precision and being able to see what's been entered without scrolling >>>>>> the text. >>>>>> >>>>>> Along the lines of what David asked, can we decide on a sufficiently >>>>>> high precision for each effect? And if some need maximal precision, live >>>>>> with the current display issue, until we override that behavior? Better >>>>>> than what we currently have. >>>>> [...] >>>>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>>>>> Track) this is clearly a regression (bug 685). >>>>>>>> >>>>>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>>>>> >>>>>>> As above, we don't really want the default tempo displayed as >>>>>>> 120.000000000000000. >>>>>> >>>>>> So are you against the width of the control, or the integer values, >>>>>> where it shows all those unnecessary zeroes? On non-integer values, for >>>>>> high precision, shouldn't it show the actual precision? >>>>> >>>>> +1 in principle to it showing the actual precision for non-integer >>>>> values. >>>>> >>>>> But I am guessing that if the default tempo was 120.000000000000000 >>>> >>>> There's no "default tempo". >>> >>> By "default tempo" I mean the value you see for "Tempo [beats per >>> minute]" in Click Track when you first open it in an Audacity session. >> >> It's blank when I open it with reset prefs. So I'm guessing that 'first >> open' is actually not 'first'. > > I really cannot understand that, Vaughan. Sorry, somehow I thought this subthread was about Change Tempo. > > Nyquist plug-ins don't remember their settings after exit of Audacity, > so after launch of Audacity (initialized .cfg or not) then launching Fwiw, it's terminologically correct to use 'launch' for apps, not for invoking features within apps. - V > Click Track, the slider widgets should always have populated text boxes > with these values: > http://manual.audacityteam.org/m/images/0/09/ClickTrackGenerator_dialog_basic7.png . > > > > Gale > > >>>>> and you tabbed into that, the selected text would only show >>>>> "0000000" give or take a digit because the selection would auto >>>>> scroll to the end. >>>> >>>> ? Clearly, we'd need to make the control wider. >>> >>> Fine, if we can. >> >> Of course we can, it's software. >> >> - V >> >> >>> >>> >>> >>> Gale >>> >>> >>>>> If that's a concern (I think it is) then we can't show more than six >>>>> or seven numbers plus the decimal separator somewhere amongst >>>>> them for the default value. >>>>> >>>>> >>>>> >>>>> >>>>> Gale >>>>> >>>>> >>>>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>>>>> it, I expect. Probably just a matter of a change of one or two >>>>>> formatting specs. >>>>>> >>>>>> >>>>>> - V >>>>>> >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>>>>> beats per min to more than two decimal places? If they do need to do >>>>>>>>> this, how many decimal places would they need? >>>>>>>> >>>>>>>> Right. So for some cases, we might want to specify the precision, and >>>>>>>> choose the other wxFloatingPointValidator constructor. >>>>>>>> >>>>>>>> The point is that these new validators are much better than previously >>>>>>>> available. And they can be overridden, to provide specific functionality >>>>>>>> we want. >>>>>>> >>>>>>> Yes, they are clearly much better, but how do we then restrict the >>>>>>> number of zeros shown? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> - V > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Gale A. <ga...@au...> - 2013-12-05 14:24:43
|
| From Vaughan Johnson <va...@au...> | Wed, 04 Dec 2013 11:14:15 -0800 | Subject: [Audacity-quality] Numerical input validation > On 12/2/2013 4:13 AM, Gale Andrews wrote: > > > > | From Vaughan Johnson <va...@au...> > > | Tue, 26 Nov 2013 22:02:37 -0800 > > | Subject: [Audacity-quality] Numerical input validation > >> On 11/26/2013 1:15 AM, Gale Andrews wrote: > >>> | From Vaughan Johnson <va...@au...> > >>> | Mon, 25 Nov 2013 11:36:03 -0800 > >>> | Subject: [Audacity-quality] Numerical input validation > >>>> On 11/25/2013 1:39 AM, Gale Andrews wrote: > >>>>> > >>>>> | From Vaughan Johnson <va...@au...> > >>>>> | Sun, 24 Nov 2013 19:06:51 -0800 > >>>>> | Subject: [Audacity-quality] Numerical input validation > >>>>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: > >>>>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: > >>>>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: > >>>>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle > >>>>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The main problem that we have with using the new validator is that > >>>>>>>>> wxFloatingPointValidator limits the precision to a specified number of > >>>>>>>>> decimal places. > >>>>>>>> > >>>>>>>> I don't think so. There are two constructors for the > >>>>>>>> wxFloatingPointValidator class. See valnum.h. > >>>>>>>> > >>>>>>>> One of them specifies limited precision, per comment "// Ctor specifying > >>>>>>>> an explicit precision." > >>>>>>>> > >>>>>>>> The other says "// Ctor using implicit (maximal) precision for this > >>>>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, > >>>>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for > >>>>>>>> the global change. > >>>>>>> > >>>>>>> I have already tried that. It works, but then the number is displayed > >>>>>>> with 15 decimal places, which is not really what we want > >>>>>> > >>>>>> So there's a little conflict here, between being able to enter very high > >>>>>> precision and being able to see what's been entered without scrolling > >>>>>> the text. > >>>>>> > >>>>>> Along the lines of what David asked, can we decide on a sufficiently > >>>>>> high precision for each effect? And if some need maximal precision, live > >>>>>> with the current display issue, until we override that behavior? Better > >>>>>> than what we currently have. > >>>>> [...] > >>>>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click > >>>>>>>>> Track) this is clearly a regression (bug 685). > >>>>>>>> > >>>>>>>> Okay, thanks. I think this can be fixed by using the other constructor. > >>>>>>> > >>>>>>> As above, we don't really want the default tempo displayed as > >>>>>>> 120.000000000000000. > >>>>>> > >>>>>> So are you against the width of the control, or the integer values, > >>>>>> where it shows all those unnecessary zeroes? On non-integer values, for > >>>>>> high precision, shouldn't it show the actual precision? > >>>>> > >>>>> +1 in principle to it showing the actual precision for non-integer > >>>>> values. > >>>>> > >>>>> But I am guessing that if the default tempo was 120.000000000000000 > >>>> > >>>> There's no "default tempo". > >>> > >>> By "default tempo" I mean the value you see for "Tempo [beats per > >>> minute]" in Click Track when you first open it in an Audacity session. > >> > >> It's blank when I open it with reset prefs. So I'm guessing that 'first > >> open' is actually not 'first'. > > > > I really cannot understand that, Vaughan. > > Sorry, somehow I thought this subthread was about Change Tempo. > > > > > > Nyquist plug-ins don't remember their settings after exit of Audacity, > > so after launch of Audacity (initialized .cfg or not) then launching > > Fwiw, it's terminologically correct to use 'launch' for apps, not for > invoking features within apps. Would "choose" or "open" be best for invoking an item from a menu? Gale > > Click Track, the slider widgets should always have populated text boxes > > with these values: > > http://manual.audacityteam.org/m/images/0/09/ClickTrackGenerator_dialog_basic7.png . > > > > > > > > Gale > > > > > >>>>> and you tabbed into that, the selected text would only show > >>>>> "0000000" give or take a digit because the selection would auto > >>>>> scroll to the end. > >>>> > >>>> ? Clearly, we'd need to make the control wider. > >>> > >>> Fine, if we can. > >> > >> Of course we can, it's software. > >> > >> - V > >> > >> > >>> > >>> > >>> > >>> Gale > >>> > >>> > >>>>> If that's a concern (I think it is) then we can't show more than six > >>>>> or seven numbers plus the decimal separator somewhere amongst > >>>>> them for the default value. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Gale > >>>>> > >>>>> > >>>>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix > >>>>>> it, I expect. Probably just a matter of a change of one or two > >>>>>> formatting specs. > >>>>>> > >>>>>> > >>>>>> - V > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Just out of curiosity, why would someone need to specify the number of > >>>>>>>>> beats per min to more than two decimal places? If they do need to do > >>>>>>>>> this, how many decimal places would they need? > >>>>>>>> > >>>>>>>> Right. So for some cases, we might want to specify the precision, and > >>>>>>>> choose the other wxFloatingPointValidator constructor. > >>>>>>>> > >>>>>>>> The point is that these new validators are much better than previously > >>>>>>>> available. And they can be overridden, to provide specific functionality > >>>>>>>> we want. > >>>>>>> > >>>>>>> Yes, they are clearly much better, but how do we then restrict the > >>>>>>> number of zeros shown? > >>>>>>> > >>>>>>> Steve > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> - V > > > > > > ------------------------------------------------------------------------------ > > Rapidly troubleshoot problems before they affect your business. Most IT > > organizations don't have a clear picture of how application performance > > affects their revenue. With AppDynamics, you get 100% visibility into your > > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > > _______________________________________________ > > Audacity-quality mailing list > > Aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-quality > > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-12-06 03:08:46
|
On 12/5/2013 6:24 AM, Gale Andrews wrote: > > | From Vaughan Johnson <va...@au...> > | Wed, 04 Dec 2013 11:14:15 -0800 > | Subject: [Audacity-quality] Numerical input validation >> On 12/2/2013 4:13 AM, Gale Andrews wrote: >>> >> >>> >>> Nyquist plug-ins don't remember their settings after exit of Audacity, >>> so after launch of Audacity (initialized .cfg or not) then launching >> >> Fwiw, it's terminologically correct to use 'launch' for apps, not for >> invoking features within apps. > > Would "choose" or "open" be best for invoking an item from a > menu? 'Open' is for files. 'Select' is most-used for menu items. - V |
From: Steve t. F. <ste...@gm...> - 2013-11-25 09:56:51
|
On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: > On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>> >>>> >>>> The main problem that we have with using the new validator is that >>>> wxFloatingPointValidator limits the precision to a specified number of >>>> decimal places. >>> >>> I don't think so. There are two constructors for the >>> wxFloatingPointValidator class. See valnum.h. >>> >>> One of them specifies limited precision, per comment "// Ctor specifying >>> an explicit precision." >>> >>> The other says "// Ctor using implicit (maximal) precision for this >>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>> but it should be an easy fix. And I'm +1 on using maximal precision for >>> the global change. >> >> I have already tried that. It works, but then the number is displayed >> with 15 decimal places, which is not really what we want > > So there's a little conflict here, between being able to enter very high > precision and being able to see what's been entered without scrolling > the text. Yes. > > Along the lines of what David asked, can we decide on a sufficiently > high precision for each effect? And if some need maximal precision, live > with the current display issue, until we override that behavior? Better > than what we currently have. Nyquist version 3 plug-ins (and earlier) have no way to specify the precision. Whatever way the widget is set up in the Audacity code applies to all Nyquist plug-ins. Steve > > >>and I don't >> know how to stop that from happening. > > It's in the code, so it can be figured out. I don't have time. > > >>Perhaps someone else could take >> a look. >> >> >>> >>> >>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>> Track) this is clearly a regression (bug 685). >>> >>> Okay, thanks. I think this can be fixed by using the other constructor. >> >> As above, we don't really want the default tempo displayed as >> 120.000000000000000. > > So are you against the width of the control, or the integer values, > where it shows all those unnecessary zeroes? On non-integer values, for > high precision, shouldn't it show the actual precision? > > Since we're using a backport of the wxWidgets valnum.c, we can just fix > it, I expect. Probably just a matter of a change of one or two > formatting specs. > > - V > > >> >>>> >>>> >>>> Just out of curiosity, why would someone need to specify the number of >>>> beats per min to more than two decimal places? If they do need to do >>>> this, how many decimal places would they need? >>> >>> Right. So for some cases, we might want to specify the precision, and >>> choose the other wxFloatingPointValidator constructor. >>> >>> The point is that these new validators are much better than previously >>> available. And they can be overridden, to provide specific functionality >>> we want. >> >> Yes, they are clearly much better, but how do we then restrict the >> number of zeros shown? >> >> Steve >> >> >>> >>> - V >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Vaughan J. <va...@au...> - 2013-11-25 19:37:58
|
On 11/25/2013 1:56 AM, Steve the Fiddle wrote: > On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: >> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>> >>>>> >>>>> The main problem that we have with using the new validator is that >>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>> decimal places. >>>> >>>> I don't think so. There are two constructors for the >>>> wxFloatingPointValidator class. See valnum.h. >>>> >>>> One of them specifies limited precision, per comment "// Ctor specifying >>>> an explicit precision." >>>> >>>> The other says "// Ctor using implicit (maximal) precision for this >>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>> the global change. >>> >>> I have already tried that. It works, but then the number is displayed >>> with 15 decimal places, which is not really what we want >> >> So there's a little conflict here, between being able to enter very high >> precision and being able to see what's been entered without scrolling >> the text. > > Yes. Right, so what's your preference? > > >> >> Along the lines of what David asked, can we decide on a sufficiently >> high precision for each effect? And if some need maximal precision, live >> with the current display issue, until we override that behavior? Better >> than what we currently have. > > Nyquist version 3 plug-ins (and earlier) have no way to specify the > precision. Whatever way the widget is set up in the Audacity code > applies to all Nyquist plug-ins. I know. I meant all the other (built-in) effects. - V > > Steve > > >> >> >>> and I don't >>> know how to stop that from happening. >> >> It's in the code, so it can be figured out. I don't have time. >> >> >>> Perhaps someone else could take >>> a look. >>> >>> >>>> >>>> >>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>> Track) this is clearly a regression (bug 685). >>>> >>>> Okay, thanks. I think this can be fixed by using the other constructor. >>> >>> As above, we don't really want the default tempo displayed as >>> 120.000000000000000. >> >> So are you against the width of the control, or the integer values, >> where it shows all those unnecessary zeroes? On non-integer values, for >> high precision, shouldn't it show the actual precision? >> >> Since we're using a backport of the wxWidgets valnum.c, we can just fix >> it, I expect. Probably just a matter of a change of one or two >> formatting specs. >> >> - V >> >> >>> >>>>> >>>>> >>>>> Just out of curiosity, why would someone need to specify the number of >>>>> beats per min to more than two decimal places? If they do need to do >>>>> this, how many decimal places would they need? >>>> >>>> Right. So for some cases, we might want to specify the precision, and >>>> choose the other wxFloatingPointValidator constructor. >>>> >>>> The point is that these new validators are much better than previously >>>> available. And they can be overridden, to provide specific functionality >>>> we want. >>> >>> Yes, they are clearly much better, but how do we then restrict the >>> number of zeros shown? >>> >>> Steve >>> >>> >>>> >>>> - V >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Steve t. F. <ste...@gm...> - 2013-11-25 20:40:21
|
I may have a solution to this problem. Just waiting on some tests - more later. Steve On 25 November 2013 19:37, Vaughan Johnson <va...@au...> wrote: > > > On 11/25/2013 1:56 AM, Steve the Fiddle wrote: >> On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: >>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>> >>>>>> >>>>>> The main problem that we have with using the new validator is that >>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>> decimal places. >>>>> >>>>> I don't think so. There are two constructors for the >>>>> wxFloatingPointValidator class. See valnum.h. >>>>> >>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>> an explicit precision." >>>>> >>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>> the global change. >>>> >>>> I have already tried that. It works, but then the number is displayed >>>> with 15 decimal places, which is not really what we want >>> >>> So there's a little conflict here, between being able to enter very high >>> precision and being able to see what's been entered without scrolling >>> the text. >> >> Yes. > > Right, so what's your preference? > > >> >> >>> >>> Along the lines of what David asked, can we decide on a sufficiently >>> high precision for each effect? And if some need maximal precision, live >>> with the current display issue, until we override that behavior? Better >>> than what we currently have. >> >> Nyquist version 3 plug-ins (and earlier) have no way to specify the >> precision. Whatever way the widget is set up in the Audacity code >> applies to all Nyquist plug-ins. > > I know. I meant all the other (built-in) effects. > > - V > >> >> Steve >> >> >>> >>> >>>> and I don't >>>> know how to stop that from happening. >>> >>> It's in the code, so it can be figured out. I don't have time. >>> >>> >>>> Perhaps someone else could take >>>> a look. >>>> >>>> >>>>> >>>>> >>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>> Track) this is clearly a regression (bug 685). >>>>> >>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>> >>>> As above, we don't really want the default tempo displayed as >>>> 120.000000000000000. >>> >>> So are you against the width of the control, or the integer values, >>> where it shows all those unnecessary zeroes? On non-integer values, for >>> high precision, shouldn't it show the actual precision? >>> >>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>> it, I expect. Probably just a matter of a change of one or two >>> formatting specs. >>> >>> - V >>> >>> >>>> >>>>>> >>>>>> >>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>> beats per min to more than two decimal places? If they do need to do >>>>>> this, how many decimal places would they need? >>>>> >>>>> Right. So for some cases, we might want to specify the precision, and >>>>> choose the other wxFloatingPointValidator constructor. >>>>> >>>>> The point is that these new validators are much better than previously >>>>> available. And they can be overridden, to provide specific functionality >>>>> we want. >>>> >>>> Yes, they are clearly much better, but how do we then restrict the >>>> number of zeros shown? >>>> >>>> Steve >>>> >>>> >>>>> >>>>> - V >>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Audacity-quality mailing list >>>> Aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>> >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Steve t. F. <ste...@gm...> - 2013-11-26 11:47:45
|
On 25 November 2013 20:40, Steve the Fiddle <ste...@gm...> wrote: > I may have a solution to this problem. > Just waiting on some tests - more later. Tests on Windows are looking good. Not quite a "perfect" solution, but a "good" solution imo. I'm looking to see if it can be improved, but if not then I think my latest patch (not posted yet) will be quite sufficient. (more later...), Steve > > Steve > > On 25 November 2013 19:37, Vaughan Johnson <va...@au...> wrote: >> >> >> On 11/25/2013 1:56 AM, Steve the Fiddle wrote: >>> On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: >>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>>> >>>>>>> >>>>>>> The main problem that we have with using the new validator is that >>>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>>> decimal places. >>>>>> >>>>>> I don't think so. There are two constructors for the >>>>>> wxFloatingPointValidator class. See valnum.h. >>>>>> >>>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>>> an explicit precision." >>>>>> >>>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>>> the global change. >>>>> >>>>> I have already tried that. It works, but then the number is displayed >>>>> with 15 decimal places, which is not really what we want >>>> >>>> So there's a little conflict here, between being able to enter very high >>>> precision and being able to see what's been entered without scrolling >>>> the text. >>> >>> Yes. >> >> Right, so what's your preference? >> >> >>> >>> >>>> >>>> Along the lines of what David asked, can we decide on a sufficiently >>>> high precision for each effect? And if some need maximal precision, live >>>> with the current display issue, until we override that behavior? Better >>>> than what we currently have. >>> >>> Nyquist version 3 plug-ins (and earlier) have no way to specify the >>> precision. Whatever way the widget is set up in the Audacity code >>> applies to all Nyquist plug-ins. >> >> I know. I meant all the other (built-in) effects. >> >> - V >> >>> >>> Steve >>> >>> >>>> >>>> >>>>> and I don't >>>>> know how to stop that from happening. >>>> >>>> It's in the code, so it can be figured out. I don't have time. >>>> >>>> >>>>> Perhaps someone else could take >>>>> a look. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>>> Track) this is clearly a regression (bug 685). >>>>>> >>>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>>> >>>>> As above, we don't really want the default tempo displayed as >>>>> 120.000000000000000. >>>> >>>> So are you against the width of the control, or the integer values, >>>> where it shows all those unnecessary zeroes? On non-integer values, for >>>> high precision, shouldn't it show the actual precision? >>>> >>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>>> it, I expect. Probably just a matter of a change of one or two >>>> formatting specs. >>>> >>>> - V >>>> >>>> >>>>> >>>>>>> >>>>>>> >>>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>>> beats per min to more than two decimal places? If they do need to do >>>>>>> this, how many decimal places would they need? >>>>>> >>>>>> Right. So for some cases, we might want to specify the precision, and >>>>>> choose the other wxFloatingPointValidator constructor. >>>>>> >>>>>> The point is that these new validators are much better than previously >>>>>> available. And they can be overridden, to provide specific functionality >>>>>> we want. >>>>> >>>>> Yes, they are clearly much better, but how do we then restrict the >>>>> number of zeros shown? >>>>> >>>>> Steve >>>>> >>>>> >>>>>> >>>>>> - V >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Audacity-quality mailing list >>>>> Aud...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Audacity-quality mailing list >>>> Aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Leland <le...@au...> - 2013-11-26 18:18:58
|
Looks like you guys have hashed this out pretty well. Is there anything I should look into? Steve, want me to help test your patch? Leland On 11/26/2013 5:47 AM, Steve the Fiddle wrote: > On 25 November 2013 20:40, Steve the Fiddle <ste...@gm...> wrote: >> I may have a solution to this problem. >> Just waiting on some tests - more later. > Tests on Windows are looking good. Not quite a "perfect" solution, but > a "good" solution imo. I'm looking to see if it can be improved, but > if not then I think my latest patch (not posted yet) will be quite > sufficient. (more later...), > > Steve > > >> Steve >> >> On 25 November 2013 19:37, Vaughan Johnson <va...@au...> wrote: >>> >>> On 11/25/2013 1:56 AM, Steve the Fiddle wrote: >>>> On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: >>>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> The main problem that we have with using the new validator is that >>>>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>>>> decimal places. >>>>>>> I don't think so. There are two constructors for the >>>>>>> wxFloatingPointValidator class. See valnum.h. >>>>>>> >>>>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>>>> an explicit precision." >>>>>>> >>>>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>>>> the global change. >>>>>> I have already tried that. It works, but then the number is displayed >>>>>> with 15 decimal places, which is not really what we want >>>>> So there's a little conflict here, between being able to enter very high >>>>> precision and being able to see what's been entered without scrolling >>>>> the text. >>>> Yes. >>> Right, so what's your preference? >>> >>> >>>> >>>>> Along the lines of what David asked, can we decide on a sufficiently >>>>> high precision for each effect? And if some need maximal precision, live >>>>> with the current display issue, until we override that behavior? Better >>>>> than what we currently have. >>>> Nyquist version 3 plug-ins (and earlier) have no way to specify the >>>> precision. Whatever way the widget is set up in the Audacity code >>>> applies to all Nyquist plug-ins. >>> I know. I meant all the other (built-in) effects. >>> >>> - V >>> >>>> Steve >>>> >>>> >>>>> >>>>>> and I don't >>>>>> know how to stop that from happening. >>>>> It's in the code, so it can be figured out. I don't have time. >>>>> >>>>> >>>>>> Perhaps someone else could take >>>>>> a look. >>>>>> >>>>>> >>>>>>> >>>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>>>> Track) this is clearly a regression (bug 685). >>>>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>>>> As above, we don't really want the default tempo displayed as >>>>>> 120.000000000000000. >>>>> So are you against the width of the control, or the integer values, >>>>> where it shows all those unnecessary zeroes? On non-integer values, for >>>>> high precision, shouldn't it show the actual precision? >>>>> >>>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>>>> it, I expect. Probably just a matter of a change of one or two >>>>> formatting specs. >>>>> >>>>> - V >>>>> >>>>> >>>>>>>> >>>>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>>>> beats per min to more than two decimal places? If they do need to do >>>>>>>> this, how many decimal places would they need? >>>>>>> Right. So for some cases, we might want to specify the precision, and >>>>>>> choose the other wxFloatingPointValidator constructor. >>>>>>> >>>>>>> The point is that these new validators are much better than previously >>>>>>> available. And they can be overridden, to provide specific functionality >>>>>>> we want. >>>>>> Yes, they are clearly much better, but how do we then restrict the >>>>>> number of zeros shown? >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>>> - V >>>>>> ------------------------------------------------------------------------------ >>>>>> Shape the Mobile Experience: Free Subscription >>>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Audacity-quality mailing list >>>>>> Aud...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Audacity-quality mailing list >>>>> Aud...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Audacity-quality mailing list >>>> Aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > |
From: Steve t. F. <ste...@gm...> - 2013-11-26 18:24:46
|
On 26 November 2013 18:18, Leland <le...@au...> wrote: > > Looks like you guys have hashed this out pretty well. Is there anything > I should look into? There could be - I'm just now looking at a couple of peculiarities and trying to work out what's going on. I've had a bit of delay here as recent code changes have trashed my build set-up so I need to fix that first. > Steve, want me to help test your patch? Yes please :-) I should have something worth testing within the next couple of hours - I'll post it to you off-list with some brief covering notes. Steve > > Leland > > > On 11/26/2013 5:47 AM, Steve the Fiddle wrote: >> On 25 November 2013 20:40, Steve the Fiddle <ste...@gm...> wrote: >>> I may have a solution to this problem. >>> Just waiting on some tests - more later. >> Tests on Windows are looking good. Not quite a "perfect" solution, but >> a "good" solution imo. I'm looking to see if it can be improved, but >> if not then I think my latest patch (not posted yet) will be quite >> sufficient. (more later...), >> >> Steve >> >> >>> Steve >>> >>> On 25 November 2013 19:37, Vaughan Johnson <va...@au...> wrote: >>>> >>>> On 11/25/2013 1:56 AM, Steve the Fiddle wrote: >>>>> On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: >>>>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> The main problem that we have with using the new validator is that >>>>>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>>>>> decimal places. >>>>>>>> I don't think so. There are two constructors for the >>>>>>>> wxFloatingPointValidator class. See valnum.h. >>>>>>>> >>>>>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>>>>> an explicit precision." >>>>>>>> >>>>>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>>>>> the global change. >>>>>>> I have already tried that. It works, but then the number is displayed >>>>>>> with 15 decimal places, which is not really what we want >>>>>> So there's a little conflict here, between being able to enter very high >>>>>> precision and being able to see what's been entered without scrolling >>>>>> the text. >>>>> Yes. >>>> Right, so what's your preference? >>>> >>>> >>>>> >>>>>> Along the lines of what David asked, can we decide on a sufficiently >>>>>> high precision for each effect? And if some need maximal precision, live >>>>>> with the current display issue, until we override that behavior? Better >>>>>> than what we currently have. >>>>> Nyquist version 3 plug-ins (and earlier) have no way to specify the >>>>> precision. Whatever way the widget is set up in the Audacity code >>>>> applies to all Nyquist plug-ins. >>>> I know. I meant all the other (built-in) effects. >>>> >>>> - V >>>> >>>>> Steve >>>>> >>>>> >>>>>> >>>>>>> and I don't >>>>>>> know how to stop that from happening. >>>>>> It's in the code, so it can be figured out. I don't have time. >>>>>> >>>>>> >>>>>>> Perhaps someone else could take >>>>>>> a look. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>>>>> Track) this is clearly a regression (bug 685). >>>>>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>>>>> As above, we don't really want the default tempo displayed as >>>>>>> 120.000000000000000. >>>>>> So are you against the width of the control, or the integer values, >>>>>> where it shows all those unnecessary zeroes? On non-integer values, for >>>>>> high precision, shouldn't it show the actual precision? >>>>>> >>>>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>>>>> it, I expect. Probably just a matter of a change of one or two >>>>>> formatting specs. >>>>>> >>>>>> - V >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>>>>> beats per min to more than two decimal places? If they do need to do >>>>>>>>> this, how many decimal places would they need? >>>>>>>> Right. So for some cases, we might want to specify the precision, and >>>>>>>> choose the other wxFloatingPointValidator constructor. >>>>>>>> >>>>>>>> The point is that these new validators are much better than previously >>>>>>>> available. And they can be overridden, to provide specific functionality >>>>>>>> we want. >>>>>>> Yes, they are clearly much better, but how do we then restrict the >>>>>>> number of zeros shown? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>>> - V >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Shape the Mobile Experience: Free Subscription >>>>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Audacity-quality mailing list >>>>>>> Aud...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Shape the Mobile Experience: Free Subscription >>>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Audacity-quality mailing list >>>>>> Aud...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Audacity-quality mailing list >>>>> Aud...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Audacity-quality mailing list >>>> Aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up now. >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Steve t. F. <ste...@gm...> - 2013-11-26 21:19:40
|
On 26 November 2013 18:24, Steve the Fiddle <ste...@gm...> wrote: > On 26 November 2013 18:18, Leland <le...@au...> wrote: >> >> Looks like you guys have hashed this out pretty well. Is there anything >> I should look into? > > There could be - I'm just now looking at a couple of peculiarities and > trying to work out what's going on. > I've had a bit of delay here as recent code changes have trashed my > build set-up so I need to fix that first. Sorry folks, I can't do anything until someone tells me how to make a patch file now that the documented commands don't work. Steve > > >> Steve, want me to help test your patch? > > Yes please :-) > I should have something worth testing within the next couple of hours > - I'll post it to you off-list with some brief covering notes. > > Steve > > >> >> Leland >> >> >> On 11/26/2013 5:47 AM, Steve the Fiddle wrote: >>> On 25 November 2013 20:40, Steve the Fiddle <ste...@gm...> wrote: >>>> I may have a solution to this problem. >>>> Just waiting on some tests - more later. >>> Tests on Windows are looking good. Not quite a "perfect" solution, but >>> a "good" solution imo. I'm looking to see if it can be improved, but >>> if not then I think my latest patch (not posted yet) will be quite >>> sufficient. (more later...), >>> >>> Steve >>> >>> >>>> Steve >>>> >>>> On 25 November 2013 19:37, Vaughan Johnson <va...@au...> wrote: >>>>> >>>>> On 11/25/2013 1:56 AM, Steve the Fiddle wrote: >>>>>> On 25 November 2013 03:06, Vaughan Johnson <va...@au...> wrote: >>>>>>> On 11/23/2013 7:48 PM, Steve the Fiddle wrote: >>>>>>>> On 24 November 2013 02:47, Vaughan Johnson <va...@au...> wrote: >>>>>>>>> On 11/23/2013 9:19 AM, David Bailes wrote: >>>>>>>>>> On Fri, Nov 22, 2013 at 3:02 PM, Steve the Fiddle >>>>>>>>>> <ste...@gm... <mailto:ste...@gm...>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The main problem that we have with using the new validator is that >>>>>>>>>> wxFloatingPointValidator limits the precision to a specified number of >>>>>>>>>> decimal places. >>>>>>>>> I don't think so. There are two constructors for the >>>>>>>>> wxFloatingPointValidator class. See valnum.h. >>>>>>>>> >>>>>>>>> One of them specifies limited precision, per comment "// Ctor specifying >>>>>>>>> an explicit precision." >>>>>>>>> >>>>>>>>> The other says "// Ctor using implicit (maximal) precision for this >>>>>>>>> type." So maybe the wrong choice of constructor was made in Nyquist.cpp, >>>>>>>>> but it should be an easy fix. And I'm +1 on using maximal precision for >>>>>>>>> the global change. >>>>>>>> I have already tried that. It works, but then the number is displayed >>>>>>>> with 15 decimal places, which is not really what we want >>>>>>> So there's a little conflict here, between being able to enter very high >>>>>>> precision and being able to see what's been entered without scrolling >>>>>>> the text. >>>>>> Yes. >>>>> Right, so what's your preference? >>>>> >>>>> >>>>>> >>>>>>> Along the lines of what David asked, can we decide on a sufficiently >>>>>>> high precision for each effect? And if some need maximal precision, live >>>>>>> with the current display issue, until we override that behavior? Better >>>>>>> than what we currently have. >>>>>> Nyquist version 3 plug-ins (and earlier) have no way to specify the >>>>>> precision. Whatever way the widget is set up in the Audacity code >>>>>> applies to all Nyquist plug-ins. >>>>> I know. I meant all the other (built-in) effects. >>>>> >>>>> - V >>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>>> >>>>>>>> and I don't >>>>>>>> know how to stop that from happening. >>>>>>> It's in the code, so it can be figured out. I don't have time. >>>>>>> >>>>>>> >>>>>>>> Perhaps someone else could take >>>>>>>> a look. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> For some Nyquist plug-ins (such as "Tempo" in Click >>>>>>>>>> Track) this is clearly a regression (bug 685). >>>>>>>>> Okay, thanks. I think this can be fixed by using the other constructor. >>>>>>>> As above, we don't really want the default tempo displayed as >>>>>>>> 120.000000000000000. >>>>>>> So are you against the width of the control, or the integer values, >>>>>>> where it shows all those unnecessary zeroes? On non-integer values, for >>>>>>> high precision, shouldn't it show the actual precision? >>>>>>> >>>>>>> Since we're using a backport of the wxWidgets valnum.c, we can just fix >>>>>>> it, I expect. Probably just a matter of a change of one or two >>>>>>> formatting specs. >>>>>>> >>>>>>> - V >>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>>>> Just out of curiosity, why would someone need to specify the number of >>>>>>>>>> beats per min to more than two decimal places? If they do need to do >>>>>>>>>> this, how many decimal places would they need? >>>>>>>>> Right. So for some cases, we might want to specify the precision, and >>>>>>>>> choose the other wxFloatingPointValidator constructor. >>>>>>>>> >>>>>>>>> The point is that these new validators are much better than previously >>>>>>>>> available. And they can be overridden, to provide specific functionality >>>>>>>>> we want. >>>>>>>> Yes, they are clearly much better, but how do we then restrict the >>>>>>>> number of zeros shown? >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>>> - V >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Shape the Mobile Experience: Free Subscription >>>>>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>>>> _______________________________________________ >>>>>>>> Audacity-quality mailing list >>>>>>>> Aud...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Shape the Mobile Experience: Free Subscription >>>>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Audacity-quality mailing list >>>>>>> Aud...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>>> ------------------------------------------------------------------------------ >>>>>> Shape the Mobile Experience: Free Subscription >>>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Audacity-quality mailing list >>>>>> Aud...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Audacity-quality mailing list >>>>> Aud...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up now. >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Audacity-quality mailing list >>> Aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality >>> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Audacity-quality mailing list >> Aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality |