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

[edgar <edg...@we...>]

 > To recap, we're talking about two things here:
 >
 > * "float" controls being treated at int. That's what Edgar was going
 > to patch.

I was never going to patch anything. ???

 > 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?

No, an error message must be returned, at least in the 'debug' window,
that's what I had said from the beginning. Ignoring a wrong value is
even worse than returning a wrong integer.

 > Is that more likely to help a Nyquist developer find the error?

Ignoring a wrong value is definitely not.

 > 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?

Only for the sake of clarification, to prevent double or triple work:

* An 'int' in a plugin 'control' line must always produce a Lisp FIXNUM,
even if the user types a float (rounding preferred over truncation).

* A 'real' in a plugin 'control' line (even if 'real' in C is an integer
or a float) must always produce a Lisp FLONUM, independent whether the
number had been typed as an integer (without a dot), as a float with a
comma separator, or as a float with a dot separator.

According to Dominik Mazzoni (long time ago) 'real' means FLONUM.

The 'real' is strictly spoken wrong, because it means 'integer or float'
and therefore equals to the general XLisp type NUMBER and not to the
XLisp type FLONUM, but it's no good idea to change this because this
surely would break many of the existing plugins.

The meaning of 'int' and 'real' in plugin 'control' lines also see:
http://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/devel/audacity-nyquist-en.htm#slider-widget

 > 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.

Yes, thank you very much.

- edgar



--
Transcript of previous messages:

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...>>  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
 >>> >>>
 >>> >>>
 > >
 > >


-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser: