[PD-dev] preparing phasor~&Co. for double precision Pd
Hans-Christoph Steiner
hans at at.or.at
Wed Jul 27 23:11:30 CEST 2011
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110727/1423edbb/attachment.htm>
More information about the Pd-dev
mailing list