Re: [Audacity-quality] Floating point input from slider widget

[Vaughan J. <va...@au...>]

On 8/27/2010 12:20 PM, Steve the Fiddle wrote:
> << * "float" controls being treated at int.>>
> Ignoring the control would be consistent with how Audacity treats other
> malformed controls, though a debug message would certainly be more
> helpful. Would it be possible to send a message to the debug window just
> to say that a control has been ignored?

Unfortunately, the place it can be detected is at startup, when all the
Nyquist plugins are loaded, in a method that parses a single line. The
debug window is used when the plugin is invoked, in a far distant piece
of code.

* I added a "float" keyword that works exactly like "real". Don't have
to document it, but it's reasonable that people would mis-recall "real"
as "float", so it might as well work. Of course, other Nyquist
interpreters won't have this, so some plugins that work in Audacity
won't work in others. I'll remove it if people think it's a bad idea.

* I added a check for "int" that creates an integer slider.

* If it's not "real", "float", or "int" it fails to create the control.
It puts up a warning alert box. This all occurs before the Audacity Log
window is created, so it does not go to the log...


That raises the general question of whether to create the log window
earlier, so the message goes to the log, but then does *not* bring up an
alert box. Comments?

I also commented out a line where logging was turned off while loading
EffectNyquist. James has asked before why the log is turned off in so
many places, and I don't see any good reason it should be turned off here.



> 
> <<Anybody know offhand whether there any cases where we pass it a float
> but do want it to return an integer?>>
> There's no worries regarding old plug-ins as slider widgets previously
> always returned a FLONUM.
> I can't think of any situation where an integer would be wanted when
> type "real" had been specified. The documentation says that the returned
> value should be a FLONUM, so if a plug-in developer requires whole
> numbers to be integers they should expect to have to code for it.

Thanks, but I meant calls to Internat::ToDisplayString(), which occur in
lots of places other than Nyquist.

- Vaughan


> 
> 
> 
> On Fri, Aug 27, 2010 at 7:56 PM, Vaughan Johnson
> <va...@au... <mailto:va...@au...>> wrote:
> 
>     Thanks, Markus!
> 
>     I'm cc-ing the Nyquist list on this, too.
> 
>     To recap, we're talking about two things here:
> 
>     * "float" controls being treated at int. That's what Edgar was going to
>     patch. I see where to do that (Nyquist.cpp line 285). Currently, not
>     just "float" but anything other than "real" is assumed to be an "int"
>     slider. Sure we want to change it to just ignore the control? Is that
>     more likely to help a Nyquist developer find the error? If so, I'll go
>     ahead and do it -- no need for a patch.
> 
>     * I'll do the change to Internat::ToDisplayString(). Anybody know
>     offhand whether there any cases where we pass it a float but do want it
>     to return an integer? If so, I can add a parameter to the method. My
>     guess is that it's always correct to return a number with a decimal
>     separator, but there are thirty-some places to check to confirm that.
> 
> 
>     On 8/26/2010 11:31 PM, Markus Meyer wrote:
>     >  Vaughan
>     >
>     > Short answer: there's no deeper reason for it. Feel free to change it.
>     >
>     > Long answer: I prefer seeing a number like "3" in the GUI instead of
>     > "3.0", but this is my personal opinion. However, one must point
>     out that
>     > "3" is a valid float value just like "3.0".
> 
>     Not to Nyquist, where (as below) "FIXNUM [is] a XLISP number without a
>     dot" and "FLONUM [is] a XLISP number with a dot". Setf looks for the dot
>     and sets the type of variable to FIXNUM or FLONUM depending on the
>     presence of the dot. Lisp is dynamically typed, not statically typed as
>     is C++.
> 
> 
>     >I did not quite understand
>     > what's outlined below but if Nyquist or the plugin interface choke on
>     > numbers if they do not have a decimal separator in it, this is a
>     bug for
>     > itself and should be fixed. This has nothing to do with the
>     > representation of the number in the GUI.
> 
>     They don't choke, it's just that a variable's type is determined at
>     runtime.
> 
>     - Vaughan
> 
> 
>     >
>     >
>     > Markus
>     >
>     > Am 27.08.2010 01:48, schrieb Vaughan Johnson:
>     >> I don't know if Edgar has completed a patch, but I think I found
>     out why
>     >> this is happening. In EffectNyquist::ProcessOne(), Markus changed the
>     >> code from using %f to Internat::ToString(), per:
>     >>
>     >>     // We use Internat::ToString() rather than "%f" here because we
>     >>     // always have to use the dot as decimal separator when giving
>     >>     // numbers to Nyquist, whereas using "%f" will use the user's
>     >>     // decimal separator which may be a comma in some countries.
>     >>
>     >> But Internat::ToString() calls Internat::ToDisplayString(). If the
>     >> precision is not specified, it strips off trailing zeroes, and if
>     it's
>     >> right at a whole number, the decimal separator, too. Note that it
>     >> doesn't do this if the precision is specified.
>     >>
>     >> So the resulting Nyquist command is, e.g., (setf input 3) instead of
>     >> (setf input 3.0).
>     >>
>     >>
>     >> I find it disturbing, for example in the sample ny plugin below,
>     that as
>     >> you move the slider, you get a series in the text field like: "2.8",
>     >> "2.9", "3". I think the last should be consistent, i.e., "3.0".
>     >>
>     >> So Markus, if you're listening, please let us know the
>     justification for
>     >> stripping all zeroes and the decimal separator. Otherwise, I'll
>     change
>     >> it to always leave at least the decimal point and one 0.
>     >>
>     >> - Vaughan
>     >>
>     >>
>     >>
>     >> On 8/25/2010 12:54 PM, Steve the Fiddle wrote:
>     >>> Regarding Slider Widgets that have the data type set to "float",
>     Edgar
>     >>> has confirmed:
>     >>>
>     >>> "This is a bug in the Nyquist plugin code. There is no type 'float'
>     >>> in the
>     >>> 'control' lines of the Audacity Nyquist interface.
>     >>> ....
>     >>> Returning an 'int' with a wrong 'float' type in the 'control'
>     line of
>     >>> a plugin is clearly a bug, an error message must be returned
>     instead."
>     >>>
>     >>> I'm not sure that Audacity should necessarily return an error
>     message.
>     >>> For other types of malformed 'control' lines Audacity simply ignores
>     >>> them. However it is clearly incorrect that an invalid data type
>     (such as
>     >>> 'float') should be accepted as an integer input slider.
>     >>>
>     >>> The problem appears to be in Nyquist.cpp where the data type is
>     checked
>     >>> to see if it is "real" and if not, sets it to "int".
>     >>> I have made a patch for Nyquist.cpp that checks against both
>     valid data
>     >>> types so that malformed (invalid data type) Slider Widgets are not
>     >>> displayed. I'll post the patch to Bugzilla along with the bug
>     >>> description.
>     >>>
>     >>> Unfortunately this patch breaks the plug-ins by Steve Jones on the
>     >>> Audacity web site, but I'll be happy to fix them when this
>     slider Widget
>     >>> issue is fixed.
>     >>>
>     >>>
>     >>> Edgar has also confirmed that:
>     >>>   "According to Dominic Mazzoni (long time ago) 'real' means
>     FLONUM".
>     >>>
>     >>> In Audacity 1.3.7, Slider Widgets that have the data type set to
>     "real"
>     >>> will always return a FLONUM (float). For Nyquist plug-ins it is
>     often an
>     >>> important difference if a slider-value is an integer or a float.
>     >>> Unfortunately recent versions of Audacity (including 1.3.12 and
>     1.3.13)
>     >>> will produce an integer if the slider value is a whole number.
>     >>>
>     >>> I am not able to offer a solution to this problem so I'll log it on
>     >>> Bugzilla as a separate bug.
>     >>>
>     >>> Steve D
>     >>>
>     >>>
>     >>>
>     >>> On Fri, Aug 20, 2010 at 6:36 PM, Steve the Fiddle
>     >>> <ste...@gm...
>     <mailto:ste...@gm...><mailto:ste...@gm...
>     <mailto:ste...@gm...>>>  wrote:
>     >>>
>     >>>      I'm not sure if this is a bug, an error in the
>     documentation, or a
>     >>>      feature request.
>     >>>
>     >>>      On this page:
>     >>>
>     >>>
>     http://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/devel/audacity-nyquist-en.htm#slider-widget
>     >>>
>     >>>      it says:
>     >>>
>     >>>      Slider Widget
>     >>>      ....
>     >>>      variable-type     -      a 'number' type:
>     >>>      int      -      integer [FIXNUM, a XLISP number without a dot]
>     >>>      real   -      floating point [FLONUM, a XLISP number with a
>     dot]
>     >>>
>     >>>
>     >>>      However, using "real" produces a "real number" not
>     necessarily a
>     >>>      flonum - it may produce a float or an integer.
>     >>>
>     >>>      Before the last changes to the Slider Widget this was not
>     >>> evident as
>     >>>      a problem.
>     >>>      (see here:
>     >>>
>     >>>
>     http://audacity.238276.n2.nabble.com/Inputting-exact-values-into-Audacity-Nyquist-effects-td3850278.html#a3850278
>     >>>
>     >>>      )
>     >>>      I'm not sure if that was because it did always produce a
>     float, or
>     >>>      if it was just that it was very unlikely that a slider
>     widget would
>     >>>      produce an integer. The test plug-in (below) in Audacity 1.2.6,
>     >>>      appears to suggest that "real" would always produce a float.
>     >>>
>     >>>      Here's a small test plug-in to demonstrate the issue:
>     >>>
>     >>>      ;nyquist plug-in
>     >>>      ;version 1
>     >>>      ;type analyze
>     >>>      ;name "A Slider Widget Test"
>     >>>      ;control input "Input" real "" 5.0 0.0 10.0
>     >>>      (if (integerp input)
>     >>>         (format NIL "input is an integer: ~a" input)
>     >>>         (format NIL "input is a float: ~a" input))
>     >>>
>     >>>
>     >>>      So far I have discovered two of my old plug-ins that have
>     broken
>     >>> due
>     >>>      to the assumption that using "real" would produce a float.
>     I've not
>     >>>      yet found any problems with any of the "official" Nyquist
>     plug-ins,
>     >>>      but it may be worth keeping an eye open for possible problems.
>     >>>
>     >>>      If this is a bug, can it be easily fixed?
>     >>>      If this is not a bug, the documentation needs updating and
>     I think
>     >>>      there is a strong case for introducing a new Slider Widget
>     variable
>     >>>      type of "float", that will always return a flonum.
>     >>>
>     >>>      Steve
>     >>>
>     >>>
>     >
>     >
> 
> 
>     ------------------------------------------------------------------------------
>     Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>     Be part of this innovative community and reach millions of netbook users
>     worldwide. Take advantage of special opportunities to increase
>     revenue and
>     speed time-to-market. Join now, and jumpstart your future.
>     http://p.sf.net/sfu/intel-atom-d2d
>     _______________________________________________
>     Audacity-quality mailing list
>     Aud...@li...
>     <mailto:Aud...@li...>
>     https://lists.sourceforge.net/lists/listinfo/audacity-quality
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> 
> 
> 
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality