[PD-dev] preparing phasor~&Co. for double precision Pd

[Hans-Christoph Steiner]

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>