Inputting exact values into Audacity Nyquist effects

13 messages

Inputting exact values into Audacity Nyquist effects

Reply Threaded

Nyquist plug-ins have a bad habit of inputting a different value to the
value shown in the plug-in interface. For example, if we want to set the
duration of the first note in a sequence, we can use a control input
like this:

;control noteduration "Length of first tone" real "seconds" 0.5 0.01 10

One might reasonably assume that the default length for the first note
is 0.5 seconds, but it actually sets a default of 0.49951 seconds.

This discrepancy of just under 5 milliseconds may not sound like much,
but the sequence is to be synchronised with a track that has a tempo of,
say, 120bpm, then the generated sequence will quite rapidly go out of
sync with the other track.

As workarounds, the user can be instructed to not use the sliders and to
always type the input (and not rely on the default). The user must also
NOT use the Tab key to move from one field to the next (which probably
makes it unusable for visually impaired users).

Alternatively a line of code such as
(if (= noteduration 0.49951)(setq noteduration 0.5))
could be added - but this is a horrible hack.

Another alternative is to find minimum and maximum values that allow the
default to be exact, for example;
;control noteduration "Length of first tone" real "seconds" 0.5 0.0 10.0
but again this is a very ugly workaround, particularly if it requires
illegal values to be used for either the minimum or maximum.

Does anyone know a better workaround - or better still, how to fix the
problem?

(This issues is currently listed as P3 and has also been raised here
http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-Audacity-td238683.html)

Steve D

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Bill Wharrie

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

On 19-Oct-09, at 1:04 PM, Steve wrote:

> Nyquist plug-ins have a bad habit of inputting a different value to
> the
> value shown in the plug-in interface. For example, if we want to set
> the
> duration of the first note in a sequence, we can use a control input
> like this:
>
> ;control noteduration "Length of first tone" real "seconds" 0.5 0.01
> 10
>
> One might reasonably assume that the default length for the first note
> is 0.5 seconds, but it actually sets a default of 0.49951 seconds.
>
> This discrepancy of just under 5 milliseconds may not sound like much,
> but the sequence is to be synchronised with a track that has a tempo
> of,
> say, 120bpm, then the generated sequence will quite rapidly go out of
> sync with the other track.
>
> As workarounds, the user can be instructed to not use the sliders
> and to
> always type the input (and not rely on the default). The user must
> also
> NOT use the Tab key to move from one field to the next (which probably
> makes it unusable for visually impaired users).
>
> Alternatively a line of code such as
> (if (= noteduration 0.49951)(setq noteduration 0.5))
> could be added - but this is a horrible hack.
>
> Another alternative is to find minimum and maximum values that allow
> the
> default to be exact, for example;
> ;control noteduration "Length of first tone" real "seconds" 0.5 0.0
> 10.0
> but again this is a very ugly workaround, particularly if it requires
> illegal values to be used for either the minimum or maximum.
>
> Does anyone know a better workaround - or better still, how to fix the
> problem?

Steve:

Would a "snap to bpm" choice be useful? Probably not, because you'd
need a huge block of code to check for everything from 64th notes to
whole notes and all the dotted variants. Hmmmm ...

What about entering bpm, then the length of the note (64th, 32nd, etc,
as a popup menu) and then a checkbox to dot the note? Three input
boxes instead of one, but at least you end up with values that will
not cause the sequence to drift against the click. The calculation
should be straightforward, and the note length will be exact.

-- Bill

>
> (This issues is currently listed as P3 and has also been raised here
> http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-Audacity-td238683.html)
>
> Steve D
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Al Dimond

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

In reply to this post by Stevethefiddle

On Monday 19 October 2009 11:04:41 Steve wrote:

> Nyquist plug-ins have a bad habit of inputting a different value to
> the value shown in the plug-in interface. For example, if we want
> to set the duration of the first note in a sequence, we can use a
> control input like this:
>
> ;control noteduration "Length of first tone" real "seconds" 0.5
> 0.01 10
>
> One might reasonably assume that the default length for the first
> note is 0.5 seconds, but it actually sets a default of 0.49951
> seconds.
>

...

>
> Does anyone know a better workaround - or better still, how to fix
> the problem?
>

It looks like any time any slider is focused all the values get
rounded to the nearest slider "tick". Slider ticks, for floating point
controls, come every 1/1000th of the range. Meanwhile the display
values are rounded to the nearest thousandth, hundredth, tenth, or
unit depending on the range. If the range is 0-30, for example,
display values are rounded to the nearest .1 and ticks are every .03.

Steve, you're comfortable applying patches and building from source,
right? I'm attaching a patch that might fix the problem, although I
don't know enough about Nyquist to know whether I did it right or not.
The basic idea is that it sends what was written to the text box
instead of the floating-point value. It doesn't work if you enter
something that doesn't look like a floating point number into the text
box, which should be fixed, but I just want to make sure I'm doing it
right in the first place. If you can't build I'll try to figure out how
to test Nyquist stuff tomorrow.

- Al

> (This issues is currently listed as P3 and has also been raised
> here
> http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-Aud
> acity-td238683.html)
>
> Steve D
>

[awd_nyquist_exact_inputs.patch]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Stevethefiddle

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

On Mon, 2009-10-19 at 23:42 -0600, Al Dimond wrote:

I'm not sure that "comfortable" is the right word, but I'll have a
go :-)

> I'm attaching a patch that might fix the problem, although I
> don't know enough about Nyquist to know whether I did it right or not.
> The basic idea is that it sends what was written to the text box
> instead of the floating-point value.

I've successfully applied the patch and it makes a big improvement in
most cases but unfortunately it introduces a new bug (which is probably
what you are referring to in your next sentence).

If we have an input:

;control test "test" real "" 1.0 0.01 2000.0

This should (ideally) display the number 1 (or 1.0000) as the default
value, but in fact it displays 0 (zero).

More importantly (because it will probably break quite a few plug-ins);
because this input is of type "real", it should _always_ produce a
float. With the patch, this example produces integers unless a float is
explicitly typed into the text entry.

> It doesn't work if you enter
> something that doesn't look like a floating point number into the text
> box, which should be fixed, but I just want to make sure I'm doing it
> right in the first place.
> If you can't build I'll try to figure out how
> to test Nyquist stuff tomorrow.

Are you aware of Leland's "Nyquist Workbench" module? It is a really
useful tool when fiddling around with Nyquist.
http://audacity.homerow.net/index.php?dir=modules

(as an aside, if you are developing on Windows and build NyqBench
against the current Audacity cvs code, I would love a copy - I'm happy
building it on Linux, but not so on Windows)

Steve

> - Al
>
> > (This issues is currently listed as P3 and has also been raised
> > here
> > http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-Aud
> > acity-td238683.html)
> >
> > Steve D
> >

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Stevethefiddle

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

In reply to this post by Al Dimond

:Oops: Seems like I made an incorrect assumption in my last post.

In Audacity 1.3.9 and earlier it appears that if the ;control type is
set to "real", it will always produce a float, but in Audacity 1.3.10,
(without the patch), inputs _can_ return integers. (There would be
problems is a float was produced when the input type was set to integer,
but I don't see any problem this way round).

Steve

On Mon, 2009-10-19 at 23:42 -0600, Al Dimond wrote:

> On Monday 19 October 2009 11:04:41 Steve wrote:
> > Nyquist plug-ins have a bad habit of inputting a different value to
> > the value shown in the plug-in interface. For example, if we want
> > to set the duration of the first note in a sequence, we can use a
> > control input like this:
> >
> > ;control noteduration "Length of first tone" real "seconds" 0.5
> > 0.01 10
> >
> > One might reasonably assume that the default length for the first
> > note is 0.5 seconds, but it actually sets a default of 0.49951
> > seconds.
> >
>
> ...
>
> >
> > Does anyone know a better workaround - or better still, how to fix
> > the problem?
> >
>
> It looks like any time any slider is focused all the values get
> rounded to the nearest slider "tick". Slider ticks, for floating point
> controls, come every 1/1000th of the range. Meanwhile the display
> values are rounded to the nearest thousandth, hundredth, tenth, or
> unit depending on the range. If the range is 0-30, for example,
> display values are rounded to the nearest .1 and ticks are every .03.
>
> Steve, you're comfortable applying patches and building from source,
> right? I'm attaching a patch that might fix the problem, although I
> don't know enough about Nyquist to know whether I did it right or not.
> The basic idea is that it sends what was written to the text box
> instead of the floating-point value. It doesn't work if you enter
> something that doesn't look like a floating point number into the text
> box, which should be fixed, but I just want to make sure I'm doing it
> right in the first place. If you can't build I'll try to figure out how
> to test Nyquist stuff tomorrow.
>
> - Al
>
> > (This issues is currently listed as P3 and has also been raised
> > here
> > http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-Aud
> > acity-td238683.html)
> >
> > Steve D
> >

Al Dimond

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

In reply to this post by Stevethefiddle

Thanks for trying that patch. There's a new patch attached. To apply
it you'll want to reverse the old one first (use patch with the -R
flag). The new patch also appears to fix the problem exhibited by the
Risset Drum plugin, which requests default values like 100 and 500 and
the dialog shows numbers like 101 and 502. More comments below.

On Tuesday 20 October 2009 12:58:06 Steve wrote:

> I've successfully applied the patch and it makes a big improvement
> in most cases but unfortunately it introduces a new bug (which is
> probably what you are referring to in your next sentence).
>
> If we have an input:
>
> ;control test "test" real "" 1.0 0.01 2000.0
>
> This should (ideally) display the number 1 (or 1.0000) as the
> default value, but in fact it displays 0 (zero).
>

Actually, that is something totally different than what I was thinking
of. Are you saying that if you set 1.0 as your default and don't
touch the slider at all that you'll get 0 as the input to the control?
If that's what you're saying, I think I know why that is, and the new
patch should fix it. If it's something else I have no idea what's
going on.

> More importantly (because it will probably break quite a few
> plug-ins); because this input is of type "real", it should
> _always_ produce a float. With the patch, this example produces
> integers unless a float is explicitly typed into the text entry.
>

I just got your other mail on this subject. The new patch will always
put three digits after the decimal point for floats (even ones with
integral values) but that's really easy to change if you or someone
else doesn't like it.

> > It doesn't work if you enter
> > something that doesn't look like a floating point number into the
> > text box, which should be fixed, but I just want to make sure I'm
> > doing it right in the first place.
> > If you can't build I'll try to figure out how
> > to test Nyquist stuff tomorrow.
>
> Are you aware of Leland's "Nyquist Workbench" module? It is a
> really useful tool when fiddling around with Nyquist.
> http://audacity.homerow.net/index.php?dir=modules
>

I am now! I'll give that a try in a bit; my Lisp skills are pretty
minimal at this point but I might understand enough to do a little
debugging, and I'm always willing to try another language.

> (as an aside, if you are developing on Windows and build NyqBench
> against the current Audacity cvs code, I would love a copy - I'm
> happy building it on Linux, but not so on Windows)
>

I'm on Linux as well so I can't really help with that... I'd give it a
shot with the mingw32 cross compiler but I don't even have Nyquist
building for mingw32 yet (it's so far from the purpose of my mingw32
tree that I just disabled it along with pretty much every other
optional feature or library).

> Steve
>
> > - Al
> >
> > > (This issues is currently listed as P3 and has also been raised
> > > here
> > >
> > > http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-
> > >Aud acity-td238683.html)
> > >
> > > Steve D
>

[awd_nyquist_exact_inputs_2.patch]

Index: src/effects/nyquist/Nyquist.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/effects/nyquist/Nyquist.cpp,v retrieving revision 1.84 diff -u -r1.84 Nyquist.cpp --- src/effects/nyquist/Nyquist.cpp 18 Sep 2009 08:18:49 -0000 1.84 +++ src/effects/nyquist/Nyquist.cpp 20 Oct 2009 21:14:48 -0000 @@ -607,13 +607,25 @@ for (unsigned int j = 0; j < mControls.GetCount(); j++) { if (mControls[j].type == NYQ_CTRL_REAL) { + // Use the value displayed in the dialog; follows logic in + // NyquistDialog::OnSlider() for number of places after the decimal + // point + int precision = mControls[j].high - mControls[j].low < 1 ? 3 : + mControls[j].high - mControls[j].low < 10 ? 2 : + mControls[j].high - mControls[j].low < 100 ? 1 : + 0; + double value = mControls[j].val; + for (int i = 0; i < precision; ++i) value *= 10; + value = floor(value + 0.5); + for (int i = 0; i < precision; ++i) value /= 10; + // 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. cmd += wxString::Format(wxT("(setf %s %s)\n"), mControls[j].var.c_str(), - Internat::ToString(mControls[j].val).c_str()); + Internat::ToString(value, 3).c_str()); } else if (mControls[j].type == NYQ_CTRL_INT || mControls[j].type == NYQ_CTRL_CHOICE) { @@ -1049,8 +1061,17 @@ wxASSERT(slider && text); int val = slider->GetValue(); - ctrl->val = (val / (double)ctrl->ticks)* + + // If the value is more than one tick different from the current value + // change it (this prevents changes from manually entered values unless + // the slider actually moved + double newVal = (val / (double)ctrl->ticks)* (ctrl->high - ctrl->low) + ctrl->low; + if (fabs(newVal - ctrl->val) >= (1 / (double)ctrl->ticks) * + (ctrl->high - ctrl->low)) + { + ctrl->val = newVal; + } wxString valStr; if (ctrl->type == NYQ_CTRL_REAL) {

edgar-rft

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

> It looks like any time any slider is focused all the values get
> rounded to the nearest slider "tick".

Yes, and I reported this bug several times in the last few years.

The same problems (inexact values) appears if you coose in Audacity
"Effect > Repeat last Effect". Audacity then re-uses the inexact
'ticks' values.

> In Audacity 1.3.9 and earlier it appears that if the ;control type is
> set to "real", it will always produce a float, but in Audacity 1.3.10,
> (without the patch), inputs _can_ return integers. (There would be
> problems is a float was produced when the input type was set to integer,
> but I don't see any problem this way round).

Maybe this information helps:

Nyquist (XLISP) auto-converts integers into floats if needed.

This means:

If the Nyquist code of an Audacity plugin expects a float of 1.0 and
Audacity gives an integer 1, Nyquist (XLISP) will auto-convert the
integer 1 into a float of 1.0 anyway (but only if a float is really
needed by the Nyquist XLISP code).

This of course does NOT work if a plugin expects a float of 1.5
and Audacity gives an integer of 1 (should be obvious).

If Nyquist expects an integer and Audacity gives a float, the float
will get truncated (0.999 -> 0), not rounded.

Please keep in mind that in most European countries floats are written
with a comma instead of a dot. If Audacity e.g. is set to "german"
locale the text input box in the Audacity interface must be capable
to convert commas into dots (dots are expected by Nyquist).

Sadly I do not have the time right now to re-compile Audacity and test
it, but probably (hopefully) I will have time at the weekend.

- edgar

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Stevethefiddle

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

In reply to this post by Al Dimond

The new patch works very well, but I don't like the reduced resolution.

In some situations it is necessary for user input to have more decimal
places than is possible with this patch. Is it possible to keep the
benefits of this patch without loosing decimal places?

Steve

On Tue, 2009-10-20 at 15:19 -0600, Al Dimond wrote:

> Thanks for trying that patch. There's a new patch attached. To apply
> it you'll want to reverse the old one first (use patch with the -R
> flag). The new patch also appears to fix the problem exhibited by the
> Risset Drum plugin, which requests default values like 100 and 500 and
> the dialog shows numbers like 101 and 502. More comments below.
>
> On Tuesday 20 October 2009 12:58:06 Steve wrote:
> > I've successfully applied the patch and it makes a big improvement
> > in most cases but unfortunately it introduces a new bug (which is
> > probably what you are referring to in your next sentence).
> >
> > If we have an input:
> >
> > ;control test "test" real "" 1.0 0.01 2000.0
> >
> > This should (ideally) display the number 1 (or 1.0000) as the
> > default value, but in fact it displays 0 (zero).
> >
>
> Actually, that is something totally different than what I was thinking
> of. Are you saying that if you set 1.0 as your default and don't
> touch the slider at all that you'll get 0 as the input to the control?
> If that's what you're saying, I think I know why that is, and the new
> patch should fix it. If it's something else I have no idea what's
> going on.
>
> > More importantly (because it will probably break quite a few
> > plug-ins); because this input is of type "real", it should
> > _always_ produce a float. With the patch, this example produces
> > integers unless a float is explicitly typed into the text entry.
> >
>
> I just got your other mail on this subject. The new patch will always
> put three digits after the decimal point for floats (even ones with
> integral values) but that's really easy to change if you or someone
> else doesn't like it.
>
> > > It doesn't work if you enter
> > > something that doesn't look like a floating point number into the
> > > text box, which should be fixed, but I just want to make sure I'm
> > > doing it right in the first place.
> > > If you can't build I'll try to figure out how
> > > to test Nyquist stuff tomorrow.
> >
> > Are you aware of Leland's "Nyquist Workbench" module? It is a
> > really useful tool when fiddling around with Nyquist.
> > http://audacity.homerow.net/index.php?dir=modules
> >
>
> I am now! I'll give that a try in a bit; my Lisp skills are pretty
> minimal at this point but I might understand enough to do a little
> debugging, and I'm always willing to try another language.
>
> > (as an aside, if you are developing on Windows and build NyqBench
> > against the current Audacity cvs code, I would love a copy - I'm
> > happy building it on Linux, but not so on Windows)
> >
>
> I'm on Linux as well so I can't really help with that... I'd give it a
> shot with the mingw32 cross compiler but I don't even have Nyquist
> building for mingw32 yet (it's so far from the purpose of my mingw32
> tree that I just disabled it along with pretty much every other
> optional feature or library).
>
> > Steve
> >
> > > - Al
> > >
> > > > (This issues is currently listed as P3 and has also been raised
> > > > here
> > > >
> > > > http://n2.nabble.com/Re-Slider-Bug-Investigations-was-Pluck-in-
> > > >Aud acity-td238683.html)
> > > >
> > > > Steve D
> >

Al Dimond

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

On Wednesday 21 October 2009 16:34:24 Steve wrote:
> The new patch works very well, but I don't like the reduced
> resolution.
>
> In some situations it is necessary for user input to have more
> decimal places than is possible with this patch. Is it possible to
> keep the benefits of this patch without loosing decimal places?
>

Of course it is possible! I was going to say, "It's possible, but
difficult," but it wasn't that hard with a different approach. This new
approach removes some code duplication, so I like it better for that
reason, too.

New patch attached. With any luck this one will actually be right.

- Al

[awd_nyquist_exact_inputs_3.patch]

Index: src/effects/nyquist/Nyquist.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/effects/nyquist/Nyquist.cpp,v retrieving revision 1.84 diff -u -r1.84 Nyquist.cpp --- src/effects/nyquist/Nyquist.cpp 18 Sep 2009 08:18:49 -0000 1.84 +++ src/effects/nyquist/Nyquist.cpp 22 Oct 2009 00:48:37 -0000 @@ -1049,22 +1049,48 @@ wxASSERT(slider && text); int val = slider->GetValue(); - ctrl->val = (val / (double)ctrl->ticks)* + + double newVal = (val / (double)ctrl->ticks)* (ctrl->high - ctrl->low) + ctrl->low; - + + // Determine precision for displayed number + int precision = ctrl->high - ctrl->low < 1 ? 3 : + ctrl->high - ctrl->low < 10 ? 2 : + ctrl->high - ctrl->low < 100 ? 1 : + 0; + + // If the value is at least one tick different from the current value + // change it (this prevents changes from manually entered values unless + // the slider actually moved) + if (fabs(newVal - ctrl->val) >= (1 / (double)ctrl->ticks) * + (ctrl->high - ctrl->low) && + fabs(newVal - ctrl->val) >= pow(0.1, precision) / 2 ) + { + // First round to the appropriate precision + newVal *= pow(10, precision); + newVal = floor(newVal + 0.5); + newVal /= pow(10, precision); + + ctrl->val = newVal; + } + wxString valStr; if (ctrl->type == NYQ_CTRL_REAL) { - if (ctrl->high - ctrl->low < 1) { - valStr = Internat::ToDisplayString(ctrl->val, 3); - } - else if (ctrl->high - ctrl->low < 10) { - valStr = Internat::ToDisplayString(ctrl->val, 2); - } - else if (ctrl->high - ctrl->low < 100) { - valStr = Internat::ToDisplayString(ctrl->val, 1); - } - else { - valStr.Printf(wxT("%d"), (int)floor(ctrl->val + 0.5)); + // If this is a user-typed value, allow unlimited precision + if (ctrl->val != newVal) + { + valStr = Internat::ToDisplayString(ctrl->val); + } + else + { + if (precision == 0) + { + valStr.Printf(wxT("%d"), (int)floor(ctrl->val + 0.5)); + } + else + { + valStr = Internat::ToDisplayString(ctrl->val, precision); + } } } else if (ctrl->type == NYQ_CTRL_INT) {

edgar-rft

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

In reply to this post by Stevethefiddle

Some practical considerations:

The smallest value with the most digits I work with every day is the
time of one sample at 384 kHz sample frequency which equals to:

0.0000026041666... seconds

In this case three digits after the dot are not sufficient.

On ther other hand, to archieve a delay from 1 to 100 samples,
probably nobody will come to the idea to implement in an Audacity
effect-box a slider with a range from e.g.

0.000002604 (1 sample) to 0.0.0002604 (100 samples)

In such a case I would either implement a slider in sample numbers
from 1 to 100 or a slider in microseconds from 2.604 to 260.4

But there exist other cases where a much higher precision is needed.

Example: The reason why the Audacity "time-stretch" effects from the
"effect" menu produce intolerable errors of several seconds if used on
files of more than e.g. one hour length is just simple the fact that
IEEE floats work with a precision of only 17 digits after the dot,
which is far less than sufficient in this case.

Conclusion:

I think for direct text input in a GUI a precision of three digits after
the dot is too little. On the other hand, the other extreme (e.g. hundred
digits) would probably make not much sense because nobody will be able
to read it anymore.

On the (third) hand a minimum of seventeen digits (equals the IEEE float
specification) will be needed to store the value as a float for re-using
it in "repeat last effect" without loss in precision, so seventeen digits
after the dot will be something like the "minimum requirement".

- edgar

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Roger Dannenberg

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

> Example: The reason why the Audacity "time-stretch" effects from the
> "effect" menu produce intolerable errors of several seconds if used on
> files of more than e.g. one hour length is just simple the fact that
> IEEE floats work with a precision of only 17 digits after the dot,
> which is far less than sufficient in this case.
>
>
Please note that several seconds per hour is is about one part in a
thousand or 3 digits of precision. double precision floats give you
enough precision to specify sample-accurate time stretching on many
hours of audio (whether time stretching algorithms do the required
fractional sample computations is a different story).

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

Stevethefiddle

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

In reply to this post by edgar-rft

On Thu, 2009-10-22 at 03:43 +0200, edgar wrote:

> Some practical considerations:
>
> The smallest value with the most digits I work with every day is the
> time of one sample at 384 kHz sample frequency which equals to:
>
> 0.0000026041666... seconds
>
> In this case three digits after the dot are not sufficient.
>
> On ther other hand, to archieve a delay from 1 to 100 samples,
> probably nobody will come to the idea to implement in an Audacity
> effect-box a slider with a range from e.g.
>
> 0.000002604 (1 sample) to 0.0.0002604 (100 samples)

That doesn't work properly in Audacity 1.3.9 anyway.
The following works providing only text input is used, but the slider
completely messes up:

;control test "Test" real "" 0.00002604 0.000002604 0.0.0002604
(format nil "You input the value: ~a
this is equivalent to ~a samples" test (/ test 0.000002604))

I don't see the fact that the slider messes up in this case to be a big
issue - who on Earth would want to do that? and as you say, there are
workarounds.

A more sensible scenario:
;control test "Test" real "" 1 0 2000000000

Audacity 1.3.9 displays the value 0 (zero) instead of 1, and the test
variable is set to zero.

With the latest patch, it displays 1, and the test variable is set to 1.

This is clearly a huge improvement and works for me.

Nice one Al, better than I was hoping for :-)
(I guess the patch should be sent to the -dev list? )

Steve

> In such a case I would either implement a slider in sample numbers
> from 1 to 100 or a slider in microseconds from 2.604 to 260.4
>
> But there exist other cases where a much higher precision is needed.
>
> Example: The reason why the Audacity "time-stretch" effects from the
> "effect" menu produce intolerable errors of several seconds if used on
> files of more than e.g. one hour length is just simple the fact that
> IEEE floats work with a precision of only 17 digits after the dot,
> which is far less than sufficient in this case.
>
> Conclusion:
>
> I think for direct text input in a GUI a precision of three digits after
> the dot is too little. On the other hand, the other extreme (e.g. hundred
> digits) would probably make not much sense because nobody will be able
> to read it anymore.
>
> On the (third) hand a minimum of seventeen digits (equals the IEEE float
> specification) will be needed to store the value as a float for re-using
> it in "repeat last effect" without loss in precision, so seventeen digits
> after the dot will be something like the "minimum requirement".
>
> - edgar

Al Dimond

Re: Inputting exact values into Audacity Nyquist effects

Reply Threaded

On Thursday 22 October 2009 11:40:01 Steve wrote:

> On Thu, 2009-10-22 at 03:43 +0200, edgar wrote:
> > Some practical considerations:
> >
> > The smallest value with the most digits I work with every day is
> > the time of one sample at 384 kHz sample frequency which equals
> > to:
> >
> > 0.0000026041666... seconds
> >
> > In this case three digits after the dot are not sufficient.
> >
> > On ther other hand, to archieve a delay from 1 to 100 samples,
> > probably nobody will come to the idea to implement in an Audacity
> > effect-box a slider with a range from e.g.
> >
> > 0.000002604 (1 sample) to 0.0.0002604 (100 samples)
>
> That doesn't work properly in Audacity 1.3.9 anyway.
> The following works providing only text input is used, but the
> slider completely messes up:
>
> ;control test "Test" real "" 0.00002604 0.000002604 0.0.0002604
> (format nil "You input the value: ~a
> this is equivalent to ~a samples" test (/ test 0.000002604))
>
> I don't see the fact that the slider messes up in this case to be a
> big issue - who on Earth would want to do that? and as you say,
> there are workarounds.
>
> A more sensible scenario:
> ;control test "Test" real "" 1 0 2000000000
>
> Audacity 1.3.9 displays the value 0 (zero) instead of 1, and the
> test variable is set to zero.
>
> With the latest patch, it displays 1, and the test variable is set
> to 1.
>
> This is clearly a huge improvement and works for me.
>
> Nice one Al, better than I was hoping for :-)
> (I guess the patch should be sent to the -dev list? )
>
>

Thanks. I'm glad it works. I just wanted to make sure you were
basically happy with it before sending it to -devel (figuring any
developers that were interested in Nyquist, and even some, like me,
that didn't know much about it, would have subscribed to this list as
well).

> Steve
>
> > In such a case I would either implement a slider in sample
> > numbers from 1 to 100 or a slider in microseconds from 2.604 to
> > 260.4
> >
> > But there exist other cases where a much higher precision is
> > needed.
> >
> > Example: The reason why the Audacity "time-stretch" effects from
> > the "effect" menu produce intolerable errors of several seconds
> > if used on files of more than e.g. one hour length is just simple
> > the fact that IEEE floats work with a precision of only 17 digits
> > after the dot, which is far less than sufficient in this case.
> >
> > Conclusion:
> >
> > I think for direct text input in a GUI a precision of three
> > digits after the dot is too little. On the other hand, the other
> > extreme (e.g. hundred digits) would probably make not much sense
> > because nobody will be able to read it anymore.
> >
> > On the (third) hand a minimum of seventeen digits (equals the
> > IEEE float specification) will be needed to store the value as a
> > float for re-using it in "repeat last effect" without loss in
> > precision, so seventeen digits after the dot will be something
> > like the "minimum requirement".
> >
> > - edgar
>