18 Nov
2013
18 Nov
'13
10:14 p.m.
I've been slowing working my way though Yoshimi, looking for bugs and trying
to understand the code, with some success. However, I've come across something
that has me completely stumped.
On a modern machine if you look in the AdSynth edit window 'Detune' shows a
variable number of trailing digits, where it should only show 2 after the
decimal point. This is also true of all cases where a recalculated slider value
is indirectly shown in an associated uneditable box. It happens nowhere else.
I've seen this on 64bit dual core AMDs and on 32bit Atoms. However, on an
AthlonXP the problem doesn't occur.
At first I thought it might be due to different version of FLTK but having tried
various releases of debian, from 'lenny' up to the current 'testing', the
*only* differentiating feature I can discover is that the AthlonXP doesn't
recognise the sse flag.
Finally, to add to the confusion, compiling on any of the other machines,
without the sse flag set, still produces the fault - I'm wondering if even
without this, some math feature is still being used that causes the fault.
Any help or suggestions would be gratefully welcomed!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
19 Nov
19 Nov
1:53 a.m.
only a guessimg but is there a snprintf involved anywhere to format the
value for output? look at other values displayed by Yoshimi gui to see how
they're done. it may be the format string has a straight %f rather
than%.2f. just a guess and sorry if you've looked at this already.
On Nov 18, 2013 9:14 PM, "Will Godfrey" <willgodfrey(a)musically.me.uk>
wrote:
I've been slowing working my way though Yoshimi,
looking for bugs and
trying
to understand the code, with some success. However, I've come across
something
that has me completely stumped.
On a modern machine if you look in the AdSynth edit window 'Detune' shows a
variable number of trailing digits, where it should only show 2 after the
decimal point. This is also true of all cases where a recalculated slider
value
is indirectly shown in an associated uneditable box. It happens nowhere
else.
I've seen this on 64bit dual core AMDs and on 32bit Atoms. However, on an
AthlonXP the problem doesn't occur.
At first I thought it might be due to different version of FLTK but having
tried
various releases of debian, from 'lenny' up to the current 'testing',
the
*only* differentiating feature I can discover is that the AthlonXP doesn't
recognise the sse flag.
Finally, to add to the confusion, compiling on any of the other machines,
without the sse flag set, still produces the fault - I'm wondering if even
without this, some math feature is still being used that causes the fault.
Any help or suggestions would be gratefully welcomed!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:01 p.m.
You could try the follow command
cc -o precision_test -lm precision_test.c
uname -p
AMD Phenom(tm) II X6 1090T Processor
# Usage: precision_test step
./precision_test 0.01 | column -t
A 1.000000000000
B 100.000000000000
A/B 0.010000000000
precision 2
If your output is different, there is a round off problem, I presume
with `rint'.
/* precision_test.c */
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>
#include <ctype.h>
int main(int argc, char **argv)
{
double A, B, s;
int i, c = 0;
char temp[32];
if (argc < 2) return 1;
s = atof(argv[1]);
/* Used in `Fl_Valuator::step' */
A = rint(s);
B = 1;
while (fabs(s-A/B) > 4.66e-10 && B<=(0x7fffffff/10)) {
B *= 10;
A = rint(s*B);
}
/* Used in `Fl_Valuator::format' to calculate the precision for snprintf */
snprintf(temp, sizeof(temp), "%.12f", A/B);
for (i=(int) strlen(temp)-1; i>0; i--)
if (temp[i]!='0') break;
for (; i>0; i--, c++)
if (!isdigit(temp[i])) break;
printf("A %.12f\nB %.12f\nA/B %.12f\nprecision %d\n", A, B, A/B, c);
return 0;
}
On Mon, Nov 18, 2013 at 09:14:44PM +0000, Will Godfrey wrote:
I've been slowing working my way though Yoshimi,
looking for bugs and trying
to understand the code, with some success. However, I've come across something
that has me completely stumped.
On a modern machine if you look in the AdSynth edit window 'Detune' shows a
variable number of trailing digits, where it should only show 2 after the
decimal point. This is also true of all cases where a recalculated slider value
is indirectly shown in an associated uneditable box. It happens nowhere else.
I've seen this on 64bit dual core AMDs and on 32bit Atoms. However, on an
AthlonXP the problem doesn't occur.
At first I thought it might be due to different version of FLTK but having tried
various releases of debian, from 'lenny' up to the current 'testing',
the
*only* differentiating feature I can discover is that the AthlonXP doesn't
recognise the sse flag.
Finally, to add to the confusion, compiling on any of the other machines,
without the sse flag set, still produces the fault - I'm wondering if even
without this, some math feature is still being used that causes the fault.
Any help or suggestions would be gratefully welcomed!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
21 Nov
21 Nov
8:22 p.m.
On Tue, 19 Nov 2013 12:58:29 +0100
Tito Latini <tito.01beta(a)gmail.com> wrote:
You could try the follow command
cc -o precision_test -lm precision_test.c
Thank you both for your suggestions. I tried that bit of code, but as I rather
expected it behaved perfectly.
The problem seems to be that, for some reason FLTKs 'step' command is being
ignored. Not only is it failing to round the values but it is also failing to
truncate them. I even tried replacing the calculated value with a simple
integer - loads of trailing zeros after the decimal point.
Yoshi is derived from Zyn, and the section of code that sends values to FLTK
for display is identical, yet Zyn doesn't show this problem. I can only guess
there is some difference in the way yoshi links to FLTK but can't imagine what
it is!
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
22 Nov
22 Nov
1:36 a.m.
On Thu, Nov 21, 2013 at 07:22:31PM +0000, Will Godfrey wrote:
Thank you both for your suggestions. I tried that bit
of code, but as I rather
expected it behaved perfectly.
The problem seems to be that, for some reason FLTKs 'step' command is being
ignored. Not only is it failing to round the values but it is also failing to
truncate them. I even tried replacing the calculated value with a simple
integer - loads of trailing zeros after the decimal point.
Yoshi is derived from Zyn, and the section of code that sends values to FLTK
for display is identical, yet Zyn doesn't show this problem. I can only guess
there is some difference in the way yoshi links to FLTK but can't imagine what
it is!
I'm noticing a possible bug generator in a diff between
`ZynAddSubFX-2.4.3' and `yoshimi-1.1.0':
diff -u ZynAddSubFX-2.4.3/src/UI/ADnoteUI.fl \
yoshimi-1.1.0/src/UI/ADnoteUI.fl | grep lrintf
+ callback {pars->VoicePar[nvoice].PVolume = lrintf(o->value());}
+ callback {pars->VoicePar[nvoice].Presonance = lrintf(o->value());}
[...]
!! | wc -l
72
The method `value' of Fl_Valuator returns a "double" and `lrintf'
requires "float".
The implementation of `lrintf' depends on the machine (for example, in
glibc-2.15, it uses the instruction CVTSD2SI for x86_64).
You could try `lrint' or the follow trick:
http://music.columbia.edu/pipermail/music-dsp/2013-September/071566.html
3 Mar
3 Mar
12:18 a.m.
On Fri, 22 Nov 2013 01:33:08 +0100
Tito Latini <tito.01beta(a)gmail.com> wrote:
On Thu, Nov 21, 2013 at 07:22:31PM +0000, Will Godfrey
wrote:
Sorry to be so incredibly slow responding... I'm now in the fortunate? position
of being able to devote a lot more time to bug hunting.
I tried your suggestion but unfortunately it made no difference.
What is even stranger is that if I compile and run the synth on an old
version of debian there is no problem. However *exactly* the same image run on
the same machine but with debian upgraded shows the fault.
A possibly significant difference is the change from FLTK V1.1 to V1.3 but
looking on their website I can find nothing that would give a clue.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Thank you both for your suggestions. I tried that
bit of code, but as I rather
expected it behaved perfectly.
The problem seems to be that, for some reason FLTKs 'step' command is being
ignored. Not only is it failing to round the values but it is also failing to
truncate them. I even tried replacing the calculated value with a simple
integer - loads of trailing zeros after the decimal point.
Yoshi is derived from Zyn, and the section of code that sends values to FLTK
for display is identical, yet Zyn doesn't show this problem. I can only guess
there is some difference in the way yoshi links to FLTK but can't imagine what
it is!
I'm noticing a possible bug generator in a diff between
`ZynAddSubFX-2.4.3' and `yoshimi-1.1.0':
diff -u ZynAddSubFX-2.4.3/src/UI/ADnoteUI.fl \
yoshimi-1.1.0/src/UI/ADnoteUI.fl | grep lrintf
+ callback {pars->VoicePar[nvoice].PVolume = lrintf(o->value());}
+ callback {pars->VoicePar[nvoice].Presonance = lrintf(o->value());}
[...]
!! | wc -l
72
The method `value' of Fl_Valuator returns a "double" and `lrintf'
requires "float".
The implementation of `lrintf' depends on the machine (for example, in
glibc-2.15, it uses the instruction CVTSD2SI for x86_64).
You could try `lrint' or the follow trick:
6:59 p.m.
On Sun, Mar 02, 2014 at 11:18:30PM +0000, Will Godfrey wrote:
What is even stranger is that if I compile and run the
synth on an old
version of debian there is no problem. However *exactly* the same image run on
the same machine but with debian upgraded shows the fault.
A possibly significant difference is the change from FLTK V1.1 to V1.3 but
looking on their website I can find nothing that would give a clue.
Now I'm using gcc-4.8.2 and I can reproduce the problem.
Only a rapid glance: with
/* From Fl_Valuator.cxx */
void Fl_Valuator::step(double s) {
if (s < 0) s = -s;
A = rint(s);
B = 1;
while (fabs(s-A/B) > epsilon && B<=(0x7fffffff/10)) {B *= 10; A =
rint(s*B);}
}
there is a roundoff error but if we use the simplest
/* From Fl_Valuator.H */
void step(double a, int b) {A = a; B = b;}
the problem disappears
--- yoshimi-1.1.0~/src/UI/ADnoteUI.fl 2013-05-08 09:47:45.000000000 +0200
+++ yoshimi-1.1.0/src/UI/ADnoteUI.fl 2014-03-03 14:41:58.054425629 +0100
@@ -89,8 +89,9 @@
} {}
Fl_Value_Output detunevalueoutput {
callback {o->value(getDetune((pars->VoicePar[nvoice].PDetuneType == 0) ?
(pars->GlobalPar.PDetuneType) : (pars->VoicePar[nvoice].PDetuneType), 0,
pars->VoicePar[nvoice].PDetune) * pars->getBandwidthDetuneMultiplier());}
- xywh {265 5 45 20} labelsize 10 align 5 minimum -5000 maximum 5000 step 0.01
textfont 1 textsize 10
- code0 {o->value(getDetune(pars->VoicePar[nvoice].PDetuneType, 0,
pars->VoicePar[nvoice].PDetune) * pars->getBandwidthDetuneMultiplier());}
+ xywh {265 5 45 20} labelsize 10 align 5 minimum -5000 maximum 5000 textfont 1
textsize 10
+ code0 {o->step(0.01, 1);}
+ code1 {o->value(getDetune(pars->VoicePar[nvoice].PDetuneType, 0,
pars->VoicePar[nvoice].PDetune) * pars->getBandwidthDetuneMultiplier());}
}
[ ... censored for avoiding noise in LAU; the complete patch is in a private msg ]
Tito Latini
7:49 p.m.
On Mon, 3 Mar 2014 18:54:26 +0100
Tito Latini <tito.01beta(a)gmail.com> wrote:
On Sun, Mar 02, 2014 at 11:18:30PM +0000, Will Godfrey
wrote:
Thanks a lot for this. It has been a nagging source of irritation for years!
--
It wasn't me! (Well actually, it probably was)
... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
What is even stranger is that if I compile and
run the synth on an old
version of debian there is no problem. However *exactly* the same image run on
the same machine but with debian upgraded shows the fault.
A possibly significant difference is the change from FLTK V1.1 to V1.3 but
looking on their website I can find nothing that would give a clue.
Now I'm using gcc-4.8.2 and I can reproduce the problem.
Only a rapid glance: with
/* From Fl_Valuator.cxx */
void Fl_Valuator::step(double s) {
if (s < 0) s = -s;
A = rint(s);
B = 1;
while (fabs(s-A/B) > epsilon && B<=(0x7fffffff/10)) {B *= 10; A =
rint(s*B);}
}
there is a roundoff error but if we use the simplest
/* From Fl_Valuator.H */
void step(double a, int b) {A = a; B = b;}
the problem disappears
--- yoshimi-1.1.0~/src/UI/ADnoteUI.fl 2013-05-08 09:47:45.000000000 +0200
+++ yoshimi-1.1.0/src/UI/ADnoteUI.fl 2014-03-03 14:41:58.054425629 +0100
@@ -89,8 +89,9 @@
} {}
Fl_Value_Output detunevalueoutput {
callback {o->value(getDetune((pars->VoicePar[nvoice].PDetuneType == 0) ?
(pars->GlobalPar.PDetuneType) : (pars->VoicePar[nvoice].PDetuneType), 0,
pars->VoicePar[nvoice].PDetune) * pars->getBandwidthDetuneMultiplier());}
- xywh {265 5 45 20} labelsize 10 align 5 minimum -5000 maximum 5000 step 0.01
textfont 1 textsize 10
- code0 {o->value(getDetune(pars->VoicePar[nvoice].PDetuneType, 0,
pars->VoicePar[nvoice].PDetune) * pars->getBandwidthDetuneMultiplier());}
+ xywh {265 5 45 20} labelsize 10 align 5 minimum -5000 maximum 5000 textfont 1
textsize 10
+ code0 {o->step(0.01, 1);}
+ code1 {o->value(getDetune(pars->VoicePar[nvoice].PDetuneType, 0,
pars->VoicePar[nvoice].PDetune) * pars->getBandwidthDetuneMultiplier());}
}
[ ... censored for avoiding noise in LAU; the complete patch is in a private msg ]
Tito Latini
3919
days inactive
4024
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
James Morris -
Tito Latini -
Will Godfrey -
Will J Godfrey