This has continued to nag at me, so I decided to make a few checks to make sure
I *really* knew what was going on. The result is that I now think that for many
years we have all been over-thinking this (including the other lot)!
First of all, the 'speed' variable is never under any circumstances less than
zero. I proved that by setting main and part keyshifts progressively lower to
-36, and then the addsynth and voice octaves to -8 also playing with the
oscillator size and sample rate. This means there can never be a problem with
+- around that point.
Also, with this specific calculation we always want to round to zero, so I
tried combinations of lrint(n) (with the environment variable set for zeroing),
or our earlier float2zero function, int(truncf(n)), static cast, and simple
int(n). I also tested with -O0, -O3 and with and without -ffast-math
Without exception simple int came out fastest! Sometimes not by much, but there
The only thing that was faster was the assembler version. It is considerably
faster but has two problems. It's specific to X86 type processors, so not
portable, and for some reason it fails when running Yoshimi as an LV2 plugin.
More tea vicar :)
Will J Godfrey
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Yoshimi source code is available from either:
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx