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