Hi,
Even without double everywhere there are improvements that could be made
to accuracy without sacrificing performance.
On 21/04/15 11:00, [email protected] wrote:
commit 68814591c121db8c613cef5d48d854db0c864d7c
Author: Miller Puckette<[email protected]>
Date: Mon Apr 20 12:08:09 2015 -0700
first cut at compiling with t_float set to double. Using some ideas
from Katja's fork of 0.43, but re-doing it with more willingness to let
objects such as bonk~ simply use 'float' when suitable.
It might be desirable to revisit phasor~, etc., whose phase accuracy
limitations are noticeable in double (not so much in single precision).
In particular, the long-varispeed example now sounds OK with
just a phasor~ driving teh read, but the phase increment is
too quantized.
Scattered things appear to need a closer look (e.g., smeck
doesn't produce any outout).
float costab[513] with linear interpolation isn't very accurate - some
points are exact, most are too close to 0, the unusual costab
initialization probably doesn't help - it could be improved by storing
values that aren't exact cos() but when interpolated the errors average
out a bit better, some above and some below the true value.
I made a 9th order polynomial approximation, it's faster than costab (at
least on my amd64 architecture / gcc version) and more accurate too:
http://mathr.co.uk/blog/2015-04-21_approximating_cosine.html
I didn't check yet whether the noise spectrum is more or less audibly
objectionable than costab. There may also be a hybrid approach that
does better on both counts (piecewise polynomials?). Also I didn't put
any work in trying to optimize costab, as I don't really understand the
tabfudge stuff properly.
Claude
--
http://mathr.co.uk
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
