ofxFft: FFTW + KISS FFT wrapper

[kylemcdonald]

The normalization I applied is to sine waves with a gain of 1, maybe if your input is peaking it creates a square-ish wave that has more energy than a sine wave? I never checked with square waves :) I'm pretty confident that the values won't be larger than 1 as long as there is no clipping happening.

[moka]

well I just play music so I cant really tell . at a certain volume it goes over one.- How Can I make it independent from the volume of the input?

[kylemcdonald]

Assuming that it's not clipping, in which case the distortion will produce bad data, you can make it independent of the input by normalizing the spectrum to the maximum value.

In one pass you look for the maximum value, then in a second you divide everything by that maximum.

If you do this constantly, you won't be able to tell the difference between "quiet" and "loud" though. So you want to have a maximum value that slowly adapts over time. This is sometimes called automatic gain control (AGC).

[moka]

thanks kyle, that makes sense and should be a good starting point! Maybe that will also get rid of the weird values :)

[kylemcdonald]

Yeah, I'm thinking more like:

Code:

// global
float runningMax = 1; // starts as 1
float agcAdapt = .1; // 0 means no agc (slow), 1 is always normalized to the current frame (fast)

// the rest happens for every fft frame
float max = 0;
for(int i = 0; i < numBands; i++) {
 if(_input[i] > max) {
  max = _input[i];
 }
}
if(max > runningMax) {
 runningMax = max;
} else {
 runningMax = (agcAdapt * max) + ((1 - agcAdapt) * runningMax);
}
for(int i=0; i<numBands; i++) {
 _input[i] /= runningMax;
}

Which might give you better results as it's applied to the entire frame instead of just the few samples that are too high.

[moka]

hey thanks, I deleted the previous post because I figgured it doesnt really work well. i will try zour suggestion!

[halfdanj]

Hey, has anybody got this to work under snow leopard? When i try to include the libfftw3 library (that i intsalled through darwinports), its tells me that its of the wrong architecture.. Any ideas?

[jroge]

as i posted it at the snow leopard thread:
snow leopard is compiling everything for 64bit by default, so you have to compile it for 32bit by changing the settings. i don't know if that works with darwinports. it didn't work with macports. so you'll probably have to download fftw and do it yourself.

best
joerg

[kylemcdonald]

ofxFftw has now been replaced by ofxFft. Download it here.

ofxFft is completely restructured. You don't call fft() and ifft() anymore, but instead:

Code:

void setSignal(float* signal);
void setCartesian(float* real, float* imag = NULL);
void setPolar(float* amplitude, float* phase = NULL);

int getSignalSize();
float* getSignal();
void clampSignal();

int getBinSize();
float* getReal();
float* getImaginary();
float* getAmplitude();
float* getPhase();

The idea is that you should be able to set one of the three representations (one time domain, two frequency domain) and get the other two. The respective FFTs and IFFTs are evaluated lazily/when requested. To do an FFT, you might say setSignal(), then getAmplitude(). To do an IFFT you might say setPolar() with some modified amplitude values, and then call getSignal().

Two demos are packaged with the source. One shows how to do a low-pass filter EQ by modifying the amplitude. The other shows how to build up a spectrogram image.

An important change from the versions posted earlier in this thread is that the "basic"/non-fftw implementation has been changed to KISS FFT. KISS FFT is BSD licensed, which offers a lot of freedom. The old code posted by Pierre isn't packaged as well, acted weird when doing the real IFFT, and, most importantly, was ambiguously licensed (it came from a numerical recipes book, which is famously restrictive, and was later modified and called LGPL).

[cloudlore]

In Xcode I got an error about malloc.h, but a quick google search gave me an answer. You change

Code:

#include <malloc.h>

in kiss_fft.h to

Code:

#include <malloc/malloc.h>

I'm new to C++ so I've got no idea how it actually works, but it compiles fine now. Hope this helps anybody!

Another fix on that thread was this:

Actually, you shouldn't need malloc.h at all, it's obsolete; including stdlib.h should take care of what malloc.h used to handle. Basically, just remove it, or #if it out

Code:

#if !defined(__APPLE__)
#include <malloc.h>
#endif

I've tried it and it seems to work as well.

[kylemcdonald]

Thanks! I've committed an updated version and uploaded a new download that removes the line completely, as stdlib.h should define malloc.

[cloudlore]

So deleting the line should be enough? Or should I download the new version?

[kylemcdonald]

So deleting the line should be enough? Or should I download the new version?

Deleting the line is enough. I just posted a new revision with only that change, because it's clearly a significant problem if it's keeping you from compiling it in xcode!

[cloudlore]

Sweet. By the way, is there any documentation for ofxFft? If not, do you have any tips for a beginner at C++? I'm already starting to battle my way through (I've begun by looking at your examples), but some simple pointers would be nice. Perhaps in the future I'll write a tutorial for other silly people like me. Something along the lines of this one: http://www.anthonymattox.com/visualizin ... processing

[kylemcdonald]

I don't have a tutorial like the link you posted... but if you can put a good one together, I'd be glad to host it and include it with the download!

The most helpful thing I can say, besides what's written in the examples, is this:

fft libraries normally hint at the fact that "fft" is a way of saying "time-domain to frequency-domain transformation". ofxFft skips this hint, and just says it explicitly by allowing you to set different representations of a signal: time domain, or one of two frequency domain representations. Whether an fft is being done is almost inconsequential, the important thing is that you are getting frequency information from a time domain representation, or vice versa.