DustFFT - in case you need an FFT :P

[Mayae]

One last thing, regarding the two-for-one-concept: Suppose i chose to do windowing using convolution, would i multiply the transforms of the window and the signal before or after the seperation?

[mystran]

One last thing, regarding the two-for-one-concept: Suppose i chose to do windowing using convolution, would i multiply the transforms of the window and the signal before or after the seperation?

I'm not quite sure why you would want to window by convolution (that just seems like it takes more computation) but .. if the window is real, then it doesn't matter.

edit: also if you want a simple convolution with mono impulse response (applied to each channel separately), you never need to actually separate the signals at all

[potato6]

Sorry for the newbie question. I would like to experiment with FFT for a convolution reverb but I don't understand why I'm getting this error: "No matching function for call to "DustFFT_fwdD""
I'm using JUCE, I created the .h as well and added to the project. Then used #include "dustfft.h" but nothing.
What should I do?

[mystran]

Sorry for the newbie question. I would like to experiment with FFT for a convolution reverb but I don't understand why I'm getting this error: "No matching function for call to "DustFFT_fwdD""
I'm using JUCE, I created the .h as well and added to the project. Then used #include "dustfft.h" but nothing.
What should I do?

I would need more information about exactly what you did in order to answer this properly, things like which compiler you are using, do you get the error in C or C++ project, are there any other diagnostics from the compiler, etc? Assuming you copied everything up to the "cut header here" line into a header, included the dustfft.c file into the project and you are not getting any error about the header include, then it should really work.

Usually "no matching function" in C++ would indicate a type-issue of some sort, which sounds a bit weird considering there aren't any overloads (it's a pure C function and usually compilers give more helpful diagnostics if there is only one alternative), but you could sanity check that you are passing a buffer of doubles (ie. for something like std::complex<double> you'll need an explicit cast).

[potato6]

Ok I finally managed to compile it without problems. But I don't know exactly how should I use it. I would like to do some kind of convolution using IRs. Can you make some usage examples or point me in the right direction?
Thanks.

[Miles1981]

BTW, do you have a repository somewhere with this FFT? starting being interested :p

[mystran]

BTW, do you have a repository somewhere with this FFT? starting being interested :p

No, not really. Just the download link (in the first post). I'll try to update it "real soon now."

[Miles1981]

Thanks
It's always good to have a fallback when you can't use a proprietary library

[Mayae]

So I just noticed the forward aligned (and maybe the others) crashes on nullptr input, and 0 size. I glanced quickly over the switch tables and it seems you handle all cases except for 0, in which case you assume the size is 8.

Not sure what your policy is about error handling in such a case, I only noticed it because generally I program as if zero is a valid size, so I don't have to have parameter validation all over the place.

[mystran]

My point of view is that a null pointer is an invalid input that indicates a programming error and should cause a consistent crash. Whether a size of zero should be handle separately is somewhat more tricky issue, I suppose I could add a branch (or maybe a consistent crash) for that.

[Mayae]

Okay. It stems from the fact that allocating a zero-sized malloc, calloc, realloc or new[] is not an error according to the standard (it just returns implementation-defined output, maybe a nullptr), and everything in the stdlib will still work (iterator patterns with begin() != end() etc.)

Another question: Do you think it would be possible to apply the two-for-one pass before the fft is done, instead of after (associative, i guess)? It's just not an easily parallelizable pass if you do other stuff as well.

[mystran]

Another question: Do you think it would be possible to apply the two-for-one pass before the fft is done, instead of after (associative, i guess)? It's just not an easily parallelizable pass if you do other stuff as well.

I'm not sure I completely understand this question. The mathematics of FFT allows the real and imaginary transforms to be separated in spectral domain. The transform is essentially the same in both directions though, so you could shuffle the data pre-transform (pretending it was spectral domain) just as well. As far as I can see the resulting data will end up in a more confusing order though, so I'm not convinced it's a good idea.

[Music Engineer]

Obviously speed is not the only reason I wrote this. I also needed the ability to easily add extra features

this is interesting - what kind of "extra features" do you have in mind? i mean the DFT/FFT input/output relationship is well defined - what could a meaningful modification/extension look like? the first thing that comes into my mind is to use decaying sinusoids instead of steady ones ...like in the laplace-or z-transform. or maybe analysis waveforms other than sinusoids?..but that's probably not what you are talking about (as, i think, the fft algorithm is not really suited for extensions of that kind - or is it? ...but all this N-th-root-of-1 business won't work anymore in a more general setting)

[mystran]

This thing can be now found in https://github.com/signaldust/DustFFT (updated original post as well)

[Music Engineer]

that's great! thanks for your consistent stream of sound advice (pun intended) and code!