[PD-dev] missing file from pd-MAIN and fftw version

IOhannes m zmoelnig zmoelnig at iem.at
Tue Sep 26 10:17:16 CEST 2006


Hans-Christoph Steiner wrote:
> 
> It would be very nice to have FFTW in Pd, its really much much faster.
> 
> .hc
> 
> On Sep 25, 2006, at 10:38 PM, Miller Puckette wrote:
> 
>> Well, I started coding for fftw-2, then found out it had already been
>> replaced with fft-3, then decided that perhaps I should just wait for
>> fftw-4 or 5.
>>
>> I didn't like the way it was done in devel (with lots of fftw-specific
>> stuff in d_fft.c).

last week frank and me were invited to a radio show (tech talk) about 
pd: we finally came to a point where the moderators got very confused, 
why fftw was NOT used in pd. so after a little generic explanation, 
frank and me looked at each other, and answered:
"well, pd is very flexible: you could write an external that does fft's 
using fftw....wait...hmmm...why has nobody done this yet?"

and that is the question: why do we necessarily need the fftw based 
fft-objects in plain pd and cannot use externals?

so i ripped the fftw-code out of tim's patch and checked it into the cvs 
as /externals/fftw/.
the objects are called [fftw~], [ifftw~], [rfftw~] and [rifftw~]

currently it seems like the code  it is not really working, the only 
object that produced any reasonable result was [rfftw~];
i guess this can be easily fixed, but i don't have the time right now to 
investigate this any further.

so the only drawback is see is: the objects are called [fftw~] instead 
of [fft~]; but lo and behold, i vaguely remembered krzysztof magic in 
cyclone, where a newly loaded class raises itself over an already 
existing class. while he is using it to overwrite objects from other 
externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this 
should not work with internals.

et voila, does this not sound good?

mfg.adsr
IOhannes




More information about the Pd-dev mailing list