Complex FFT

[Owen Green]

Would it be painful to have the option of a full spectrum FFT, for those special ocassions, and even more nerdily, an(other) FFT object that could take complex input?

[Alex Harker]

No, but convince me why you need it.

I am yet to find an audio problem that cannot be solved using a real FFT (I used to use the complex FFT for a couple of things, but they CAN be refactored as real only, although perhaps in a slightly painful way.

So - use cases please! I suspect this might arrive as options for fl.fft~ and fl.ifft~ rather than new objects, but first tell me what you need it for.

[Owen Green]

I thought one needed complex FFTs for cepstral smoothing (and by extension true envelope / true amplitude envelope) algos, but maybe they can be refactored as real. Certainly the IRCAM implementation of ceptral smoothing takes the IFFT of the complex log of an FFT to get the cepstrum.

Considerably more speculatively, I've been quite interested in some things that attempt to do useful analysis on the noncircularity of non-ideal complex signals (e.g http://ieeexplore.ieee.org/document/7156090/). But I might have misunderstood the need for a two-sided DFT in these.

[Alex Harker]

Probably it is easiest to do some of these things with a complex FFT. Things I've done in the past (like homomorphic deconvolution) can be refactored, but the refactoring is not so simple.

How would you feel about three modes: real complex full_spectrum?

The last of these would be real input for FFT and output for iFFT but full spectrum in-between.

The only complexity is whether the data should be validated on input to the iFFT in full_spectrum mode, or converted using a complex FFT (not outputting the imag part) or just assume that the first half is good, as there is a possibility that the second half is not the complex conjugates of the first as it should be.

Thoughts?

[Owen Green]

Sounds good. Presumeably the modes of the forward and inverse objects wouldn't need to be coupled, to allow for situations where you want real input and complex output (e.g. Hilbert transformer).

I'd think that light-touch validation would be fine – i.e. it's the user's responsibility to not put garbage in.

[Pierre Alexandre Tremblay]

+1 on user responsibility - putting the onus on high-quality tutorials and learning material though... @weefuzzy are you documenting your learning curve/process?

[Owen Green]

Of course <cough>. Yesterday's e-mail / issue exchanges serve quite well to document my various sources of confusion – I've not yet done owt today, but will make sure to document as I go.

[Pierre Alexandre Tremblay]

This was definitely more as an interested party than flucoma-related - although I admit the line is quite blurred - I am yet to dig into learning the language and offered @ajharker to document the hurdles a creative coder would have. Someone with your (better) fluency will have a different experience than me, so it will be helpful to this project to have that info I think...

[Alex Harker]

Currently I am interested in having people use it to ensure it works and get interesting reflections on issues with the functionality. I know PA is concerned with documentation, but I need to know the hurdles now to make it better. Documenting it once it is in good shape will be a lot easier, but finding users who will push the development is hard, so PA I'd prefer you not to wait till it reaches some kind of maturity, as it doesn't align with my priorities with the project - Thanks.

[Alex Harker]

This is included in the next version.