pd-cvs-request@iem.at wrote:
Message: 4 Date: Sat, 03 Jun 2006 19:13:09 +0000 From: Miller Puckette millerpuckette@users.sourceforge.net Subject: [PD-cvs] pd/portaudio/pa_win_wdmks pa_win_wdmks.c, 1.3, 1.4 readme.txt, 1.1, 1.2 To: pd-cvs@iem.at Message-ID: mailman.3.1149415202.953.pd-cvs@iem.at
Update of /cvsroot/pure-data/pd/portaudio/pa_win_wdmks In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12672/pd/portaudio/pa_win_wdmks
Log Message: FFT package selection
great news!
i see that there is now a "--enable-fftw" flag to configure. however, the joy is only half of what it could be, since enabling fftw makes make look for d_fft_fftw.c which seems+ to be missing after a fresh check out.
miller, please submit d_fft_fftw.c (and d_fft_fftsg.c when you are at it)
mfga.sdr. IOhannes
On 6 Jun 2006, at 13:34, IOhannes m zmoelnig wrote:
pd-cvs-request@iem.at wrote:
To: pd-cvs@iem.at Message-ID: mailman.3.1149415202.953.pd-cvs@iem.at Update of /cvsroot/pure-data/pd/portaudio/pa_win_wdmks In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12672/pd/ portaudio/pa_win_wdmks Log Message: FFT package selection
great news!
i see that there is now a "--enable-fftw" flag to configure. however, the joy is only half of what it could be, since enabling fftw makes make look for d_fft_fftw.c which seems+ to be missing after a fresh check out.
miller, please submit d_fft_fftw.c (and d_fft_fftsg.c when you are at it)
May I ask, has this actually happened yet?
Cheers,
David
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
cheers Miller
On Fri, Jun 16, 2006 at 11:54:39AM +0100, David Plans Casal wrote:
On 6 Jun 2006, at 13:34, IOhannes m zmoelnig wrote:
pd-cvs-request@iem.at wrote:
To: pd-cvs@iem.at Message-ID: mailman.3.1149415202.953.pd-cvs@iem.at Update of /cvsroot/pure-data/pd/portaudio/pa_win_wdmks In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12672/pd/ portaudio/pa_win_wdmks Log Message: FFT package selection
great news!
i see that there is now a "--enable-fftw" flag to configure. however, the joy is only half of what it could be, since enabling fftw makes make look for d_fft_fftw.c which seems+ to be missing after a fresh check out.
miller, please submit d_fft_fftw.c (and d_fft_fftsg.c when you are at it)
May I ask, has this actually happened yet?
Cheers,
David
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
hi miller,
On Fri, 2006-06-16 at 07:15 -0700, Miller Puckette wrote:
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
i guess, you're familiar with my code from devel?
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
The aim of education is the knowledge, not of facts, but of values William S. Burroughs
On 16 Jun 2006, at 15:34, Tim Blechmann wrote:
On Fri, 2006-06-16 at 07:15 -0700, Miller Puckette wrote:
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
i guess, you're familiar with my code from devel?
I was just going to mention that. FFTW3 is definitely stable and robust, and Tim's code is there.
Just a thought.
David
Yes, but Tim's code addresses the FFTW API directly inside d_fft.c, which I think should be free of package-dependent code. (I'm not putting SSE or Altivec code in "d_*.c" files either for the same reason.)
cheers M
On Fri, Jun 16, 2006 at 03:41:07PM +0100, David Plans Casal wrote:
On 16 Jun 2006, at 15:34, Tim Blechmann wrote:
On Fri, 2006-06-16 at 07:15 -0700, Miller Puckette wrote:
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
i guess, you're familiar with my code from devel?
I was just going to mention that. FFTW3 is definitely stable and robust, and Tim's code is there.
Just a thought.
David
On Fri, 16 Jun 2006, Miller Puckette wrote:
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
Might be nice to have the stub anyhow, when looking for an FFT that supports fixed-point, I stumbled over this:
http://kissfft.sourceforge.net/ (also supports floating point)
Günter
cheers Miller
On Fri, Jun 16, 2006 at 11:54:39AM +0100, David Plans Casal wrote:
On 6 Jun 2006, at 13:34, IOhannes m zmoelnig wrote:
pd-cvs-request@iem.at wrote:
To: pd-cvs@iem.at Message-ID: mailman.3.1149415202.953.pd-cvs@iem.at Update of /cvsroot/pure-data/pd/portaudio/pa_win_wdmks In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12672/pd/ portaudio/pa_win_wdmks Log Message: FFT package selection
great news!
i see that there is now a "--enable-fftw" flag to configure. however, the joy is only half of what it could be, since enabling fftw makes make look for d_fft_fftw.c which seems+ to be missing after a fresh check out.
miller, please submit d_fft_fftw.c (and d_fft_fftsg.c when you are at it)
May I ask, has this actually happened yet?
Cheers,
David
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Fri, 16 Jun 2006, geiger wrote:
On Fri, 16 Jun 2006, Miller Puckette wrote:
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
Might be nice to have the stub anyhow, when looking for an FFT that supports fixed-point, I stumbled over this: http://kissfft.sourceforge.net/ (also supports floating point)
For the rest of us, how does kissfft in _floating_-point mode compare with FFTW3 ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Fri, 16 Jun 2006, geiger wrote:
On Fri, 16 Jun 2006, Miller Puckette wrote:
No... my fftw stub doesn't work! I designed the fft-plugin setup for FFTW2 only to discover that they changed the API entirely since then, and now am wondering if they're stable enough to try to support.
Might be nice to have the stub anyhow, when looking for an FFT that supports fixed-point, I stumbled over this: http://kissfft.sourceforge.net/ (also supports floating point)
For the rest of us, how does kissfft in _floating_-point mode compare with FFTW3 ?
Quoting the kiss_fft readme:
BACKGROUND:
I started coding this because I couldn't find a fixed point FFT that didn't use assembly code. I started with floating point numbers so I could get the theory straight before working on fixed point issues. In the end, I had a little bit of code that could be recompiled easily to do ffts with short, float or double (other types should be easy too).
Once I got my FFT working, I was curious about the speed compared to a well respected and highly optimized fft library. I don't want to criticize this great library, so let's call it FFT_BRANDX. During this process, I learned:
1. FFT_BRANDX has more than 100K lines of code. The core of kiss_fft is about 500 lines (cpx 1-d ). 2. It took me an embarrassingly long time to get FFT_BRANDX working. 3. A simple program using FFT_BRANDX is 522KB. A similar program using kiss_fft is 18KB. 4. FFT_BRANDX is roughly twice as fast as KISS FFT in default mode.
It is wonderful that free, highly optimized libraries like FFT_BRANDX exist. But such libraries carry a huge burden of complexity necessary to extract every last bit of performance.
Sometimes simpler is better, even if it's not better.
Ciao
On 19 Jun 2006, at 21:43, Frank Barknecht wrote:
It is wonderful that free, highly optimized libraries likeFFT_BRANDX exist. But such libraries carry a huge burden of complexity necessary to extract every last bit of performance.
Sometimes simpler is better, even if it's not better.
I couldn't agree more. Amen.
That argument alone is worth trying it.
d
On Mon, 19 Jun 2006, Frank Barknecht wrote:
It is wonderful that free, highly optimized libraries like FFT_BRANDX exist. But such libraries carry a huge burden of complexity necessary to extract every last bit of performance. Sometimes simpler is better, even if it's not better.
Sometimes something complex is not "better", it's just the only choice.
For the case of Pd's audio, people are used to be limited to power-of-two blocksizes and there's only one dimension to take care of, so kiss_fft can be an idea... *if* FFT_BRANDX really means FFTW and that kiss_fft really is faster than that and in which year(s) (for which versions) it is/was true.
For GridFlow, I need to support multidimensional FFT on interleaved data, with non-power-of-two index ranges. E.g. with a 240x320x3 image, do a FFT of 240 elements along each column/channel combination, a FFT of 320 elements along each row/channel combination, and not doing FFT in the third direction (channels) which is what i call "interleaved" here.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 19 Jun 2006, Frank Barknecht wrote:
It is wonderful that free, highly optimized libraries like FFT_BRANDX exist. But such libraries carry a huge burden of complexity necessary to extract every last bit of performance. Sometimes simpler is better, even if it's not better.
Sometimes something complex is not "better", it's just the only choice.
For the case of Pd's audio, people are used to be limited to power-of-two blocksizes and there's only one dimension to take care of, so kiss_fft can be an idea... *if* FFT_BRANDX really means FFTW and that kiss_fft really is faster than that and in which year(s) (for which versions) it is/was true.
I'm quite sure, that FFT_BRANDX means FFTW, however kiss isn't faster, it's slower than FFTW:
"4. FFT_BRANDX is roughly twice as fast as KISS FFT in default mode."
The kiss author later also writes, one should not "use Kiss if you need the Fastest Fourier Transform in the World", which is another play with FFTW.
There are some little benchmarks included in kiss_fft, so you may want to try it yourselfs.
Ciao
On 20 Jun 2006, at 05:44, Frank Barknecht wrote:
Sometimes something complex is not "better", it's just the only choice.
I'm quite sure, that FFT_BRANDX means FFTW, however kiss isn't faster, it's slower than FFTW:
Indeed, I was agreeing with the fact that slower isn't necessarily a bad thing, considering the reduction in complexity.
But I understand Mathieu's argument, since it's about logistics, not speed, necessarily (for him).
d
On Tue, 20 Jun 2006, David Plans Casal wrote:
On 20 Jun 2006, at 05:44, Frank Barknecht wrote:
Sometimes something complex is not "better", it's just the only choice.
I'm quite sure, that FFT_BRANDX means FFTW, however kiss isn't faster, it's slower than FFTW:
Indeed, I was agreeing with the fact that slower isn't necessarily a bad thing, considering the reduction in complexity.
But I understand Mathieu's argument, since it's about logistics, not speed, necessarily (for him).
My main argument was in favour of having an FFT hook, FFTW's speed is really an advantage which comes for free (in most cases). There are cases where one would prefer another FFT library, so having a hook to be able to use different versions is a good idea.
Günter
d
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
David Plans Casal -
Frank Barknecht -
geiger -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann