Hey Katya,
I'm very happy you're working on this, I think its a big and very
valuable step for Pd for many reasons. For me, things like accessing
large arrays and also working with UNIX timestamps and other large
integers directly, make Pd a lot easier in cases that touch on those
limitations. It brings Pd 99% to the goal of having a generic
"number" type that handles all the floats and ints that are used with
any frequency.
Sounds like you've done a fair amount of testing. I think the big
question that needs to be answered before this gets included is: can
this be done without majoring impacting 32-bit operation? It sounds
like you've covered that already. As for 64-bit floats to output, a
quick hack to get things working is to just hammer samples down to 32-
bits...
.hc
On Jul 27, 2011, at 3:39 AM, katja wrote:
Hello,
Triggered by a recent thread (http://lists.puredata.info/pipermail/pd-dev/2011-07/017022.html
) I've written alternative code for Pd classes like phasor~, osc~,
and vcf~, in preparation for double precision builds of Pd. These
classes currently employ Hoeldrich's method, a fascinating type
punning trick for optimization of phase-wrapping jobs. Considering
available data types in C, this method can not be translated to
double precision input/output format.
Phasor~ and osc~ are typically used by the dozens in Pd setups, and
even a modest performance loss could be a show stopper for setups
which are on the limit of acceptable CPU load. Fortunately it was
possible to define double-ready versions without performance loss,
by tedious elimination of redundancy instead of fancy bit hacking.
How often must a phase be wrapped? Even at high frequencies like
half the Nyquist rate, only one in four iterations goes out of
bounds. On average it proves efficient to do the phase wrapping
conditionally. Phasor~ profits most, being up to three times faster
than before, at moderate frequencies. The others did not speed up so
much, but at least none of them is slower than the original version,
when both are compared within the same Pd build. Also, the
alternative versions do not suffer from phase drift, like the
Hoeldrich versions do. I have tested this on OSX / IntelMac for
single and double precision builds. Performance may be different on
other platforms / architectures. Macro PD_BIGORSMALL was redefined
to work with arbitrary precision.
A Pd running with PD_FLOATTYPE double immediately shouted at me that
there's a lot more work to do. The audio API (PortAudio in this
case) couldn't handle 64 bit output samples from dac~. Vectors are
apparently read as type float, and maximum level digital noise is
the useless output. I've not delved into this yet. Internally things
seems to work well, for what I've seen so far.
Ah, almost forgot to mention the pro's of a double precision Pd, if
it will ever work:
- indexing of large audio buffers with ample resolution for
interpolation
- accurate sine and sinc of small angles, useful for things like
fractional delay
- FFT with frames larger than 2^17, I hope
- long sine sweeps without artifacts
- probably many more of such meticulous dsp jobs, you name them
If you're interested in double precision Pd, please find the
attached pd_doubletest.zip with C code and test-patches. Let me know
if you have test results on different platforms, or if you find
stupid bugs in my code. Is anyone working on other aspects of double
precision Pd? I'd like to join forces.
Katja Vetter
<pd_doubletest.zip>_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev