[PD-dev] rfft~ behaviour

[Tim Blechmann]

hi all,

> > but i realized that the imaginary output of the fftw library is
> > negative, the imaginary output of pd's fft is positive ... or to be
> > exact, the output of fftw and pd's fft are complex conjugated ...
> >
> > any idea, what could cause this?
> 
> Just a guess, but this might be an interpretation issue of what a
> rfft is. As it just throws away half of the spectrum, it seems
> that they don't agree on which half has to be thrown away.
i'm working on the guru interface that's working better on pd's way of
handling complex numbers ... 
would there be any problem if we take fftw's complex conjugated output
instead of pd's way of output? i don't know if it makes any difference
on with dsp applications, and i don't want to change the behaviour of an
internal object, unless there is no real difference between the two
behaviours for pd users ...
i mean using a rfft~ object with an rifft~ object would'n make any
difference, but if you combine a real with a complex fft object, there
could be some issues ...

the difference in cpu expenses would be a memcpy of the imaginary
samples to a memcpy and inverting of the imaginary samples ...
the inverting wouldn't be that expensive, but if we wouldn't need it at
all, it wouldn't be that bad ...

cheers...

 Tim                          mailto:TimBlechmann at gmx.de
                              ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
                                                          Jack Kerouac