[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