FFT and IFFT question

Jul 7, 2008 at 10:51pm

FFT and IFFT question

if an fft is performed on a peice of audio, then an inverse fft is performed, the original audio is reproduced perfectly, but i’ve never understood why this is – where in a series of frequency bins is the information about time retained? i would have expected the frequencies detected to be smeared across the entire period being analysed. why doesn’t this happen?

and would there be any way to intentionally acheive this smearing, other than having a massive bank of oscillators equal to the number of bins?

#38781
Jul 8, 2008 at 12:31am

Wihin a single frame (time duration) of an FFT, there is indeed no time information, i.e. the frequncy information is smeared across the entire frame. The process is a bit more complicated in order to reflect changes over time.

In essence, a number of short-duration FFTs are taken one after another in sequence and the changes in the amplitude & phase of the frequency bins between each of these frame consitututes the changing information over time. The longer each of the frames, the better the frequency resolution but the more the temporal smearing (i.e. poorer time resolution) and vice versa. Getting a good FFT of a quickly-changing signal is a tradeoff between frequency and temporal accuracy.

The disjunctions across frame edges are handled by ‘windowing’ each frame to shape the amount and character of the overlap between successive frames – altering the quality in various ways.

I’d reccomend a perusal of any good computer music or digital audio text – Roads, Moore, and Dodge/Jerse are good starting points.

#135541
Jul 8, 2008 at 1:15am

but i’m not doing a partitioned fft – just taking the entire contents of a buffer~ and doing a single very big fft. maybe i should say dft, because the fftw library i’m using (http://www.fftw.org/) doesnt even seem to require that the size is a power of 2… hmm. maybe fftw is doing something internally that i’m unaware of

#135542
Jul 8, 2008 at 8:47am

pete schrieb:
> if an fft is performed on a peice of audio, then an inverse fft is
> performed, the original audio is reproduced perfectly, but i’ve never
> understood why this is – where in a series of frequency bins is the
> information about time retained?

The short answer is: the information is in the phase, or more exactly in
the difference between the phase value of a specific bin in consecutive
frames…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#135543
Jul 8, 2008 at 8:56am

ah, i suspected it might be something to do with that.. so if i set the phase of everything to 0 before doing the IFFT, then it will be entirely “smeared”? i’ll give it a go.

#135544
Jul 8, 2008 at 3:51pm

Does that mean that the phase difference is interpolated
when run through the IFFT?

#135545
Jul 9, 2008 at 7:56am

Anthony Palomba schrieb:
> Does that mean that the phase difference is interpolated
> when run through the IFFT?

Think of it as if there are two sine waves with a small difference in
frequency (within the band of a single bin). Then you overlap them with
the window function… That creates something like an interpolation, but
not exactly… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#135546
Jul 9, 2008 at 9:37am

> Think of it as if there are two sine waves with a small difference in
> frequency (within the band of a single bin). Then you overlap them with
> the window function… That creates something like an interpolation, but
> not exactly… ;-)

hang on, there is no window function in what i’m talking about (i think) just a single fft..

#135547
Jul 9, 2008 at 10:24am

> Wihin a single frame (time duration) of an FFT, there is indeed no
> time information, i.e. the frequncy information is smeared across
> the entire frame.

i wouldn’t say this is entirely true.
the time information is in there (otherwise you couldn’t transform
the data back without loss),
but you can’t “easily see” it.
it’s the same as when you try to “see” the frequency information in
a time domain representation.

in both cases all information is there, but you use different kind of
representations to have access to what you are interested in.

one way to get rid of the time information is indeed to zero-out the
phases.
but then you will loose a lot of the frequency information, too.
(phase is a complex animal…)
the resulting sound will always have a harmonic spectrum based on the
delta bin freq of the fft (with an fft size of 1024 this will be
around 43 Hz).

if you are talking about a really large fft/dft, then this could
work, as your frequency bin resolution is very high – resulting in a
very low fundamental.

volker.

#135548
Jul 9, 2008 at 11:06am

> if you are talking about a really large fft/dft, then this could
> work, as your frequency bin resolution is very high – resulting in a
> very low fundamental.

it is a very large fft indeed. the trouble is, removing the phase resulted in a big attack at the start of the IFFT audio result, since all the frequencies were in phase with each other initially. i’ve also tried randomising the phase of each bin, which works really well, but is still not perfect because it seems that time based information is still there in some way, even if a random way, in the interactions between frequencies – destructive/constructive interference etc.

what i really want is for the resulting sound to remain as static as possible, as if there were a bank of unchanging oscillators as big as the number of frequency bins, with each its amplitude set by the magnitude from the fft. of course, there would still be interference between frequencies here, but not in a “set” repeating pattern of the length of the original audio.

#135549
Jul 9, 2008 at 11:51am

On 09 Jul 2008, at 13:06, pete wrote:
>
>> if you are talking about a really large fft/dft, then this could
>> work, as your frequency bin resolution is very high – resulting in a
>> very low fundamental.
>
> it is a very large fft indeed. the trouble is, removing the phase
> resulted in a big attack at the start of the IFFT audio result,
> since all the frequencies were in phase with each other initially.
> i’ve also tried randomising the phase of each bin, which works
> really well, but is still not perfect because it seems that time
> based information is still there in some way, even if a random way,
> in the interactions between frequencies – destructive/constructive
> interference etc.
>
> what i really want is for the resulting sound to remain as static
> as possible, as if there were a bank of unchanging oscillators as
> big as the number of frequency bins, with each its amplitude set by
> the magnitude from the fft. of course, there would still be
> interference between frequencies here, but not in a “set” repeating
> pattern of the length of the original audio.
>

yes, randomizing the phases is the better way. i have just tried it
and it sounds very nice.

as i said, when you mess with the phases, you will loose frequency
information, resulting in a purely harmonic sound with a fundamental
corresponding to the size of the fft (number of bins). if the fft is
large you might get a good enough frequency resolution cause the
fundamental is very low. but although the periodicy of the harmonic
sound might not be perceived as an audible pitch, it still repeats
periodically, i.e. you hear it as a repeating rhythm.

is that what you are talking about?
maybe you can upload the original and processed sound somewhere to
compare results.

volker.

#135550
Jul 9, 2008 at 1:14pm

Ahh yes, sorry for mis-stating the case. In my haste I conflated frequency and phase.

#135551
Jul 9, 2008 at 1:23pm

> yes, randomizing the phases is the better way. i have just tried it
> and it sounds very nice.
>
> as i said, when you mess with the phases, you will loose frequency
> information, resulting in a purely harmonic sound with a fundamental
> corresponding to the size of the fft (number of bins). if the fft is
> large you might get a good enough frequency resolution cause the
> fundamental is very low. but although the periodicy of the harmonic
> sound might not be perceived as an audible pitch, it still repeats
> periodically, i.e. you hear it as a repeating rhythm.
>
> is that what you are talking about?
> maybe you can upload the original and processed sound somewhere to
> compare results.

original:

http://www.thirdmeaning.net/misc/guitarscale.wav

processed (looped, with overlapped windowing):

http://www.thirdmeaning.net/misc/outputtest.wav

you can hear the “pulsing” which is the length of the file, which you would of course expect, but the question is, is there a way to avoid this, to just generate the frequencies at the right magnitudes infinitely, rather than just creating something the same length as the input and then looping it.

if so then it would still have periodicity as you say, but i think it would be far less obvious, and very large.

#135552
Jul 9, 2008 at 2:27pm

>
> original:
> http://www.thirdmeaning.net/misc/guitarscale.wav
>
> processed (looped, with overlapped windowing):
> http://www.thirdmeaning.net/misc/outputtest.wav
>
> you can hear the “pulsing” which is the length of the file, which
> you would of course expect,

the pulsing i hear in your processed sound is much shorter than the
size of the original file.
so i guess there’s still something wrong in how you calculate the thing.

compare it to this one:

http://www.esbasel.ch/Downloads/outputtest-vb.wav

this has a period of roughly 3 secs, since the fft routine i use can
only process file lengths that are powers of two.

> but the question is, is there a way to avoid this, to just generate
> the frequencies at the right magnitudes infinitely, rather than
> just creating something the same length as the input and then
> looping it.
>

hm, you would need an oscillatorbank or a realtime version of the
ifft (of the same size as your fft).
then find the peaks and calculate the true frequencies (from phase
increment or magnitudes) etc.
quite expensive for large fft sizes.

if you don’t take the infinity too seriously, you could also use an
fft which is even larger than your file, and zero-pad the rest of the
frame.

this file is processed from a frame size of 524288 samples (~12sec.)

http://www.esbasel.ch/Downloads/outputtest-vb2.wav

volker.

#135553
Jul 9, 2008 at 5:01pm

pete schrieb:
> you can hear the “pulsing” which is the length of the file, which you
> would of course expect, but the question is, is there a way to avoid
> this, to just generate the frequencies at the right magnitudes
> infinitely, rather than just creating something the same length as
> the input and then looping it.

If you randomise the phase each time you play the complete frame it
should not pulse any more if you have the ideal windowing. But maybe you
need a really good random generator, which is the domain of Peter
Castine’s objects…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#135554
Jul 9, 2008 at 5:20pm

> the pulsing i hear in your processed sound is much shorter than the
> size of the original file.
> so i guess there’s still something wrong in how you calculate the thing.

maybe it’s because of my overlapping and adding with a window?

>
> compare it to this one:
> http://www.esbasel.ch/Downloads/outputtest-vb.wav
>
> this has a period of roughly 3 secs, since the fft routine i use can
> only process file lengths that are powers of two.

yes, this sounds much better. how are you looping the result? (wouldnt there be a click if you just looped it straight?)

> hm, you would need an oscillatorbank or a realtime version of the
> ifft (of the same size as your fft).
> then find the peaks and calculate the true frequencies (from phase
> increment or magnitudes) etc.
> quite expensive for large fft sizes.

sounds difficult..

> if you don’t take the infinity too seriously, you could also use an
> fft which is even larger than your file, and zero-pad the rest of the
> frame.

this sounds like a very good idea, so the magnitudes would remain unnaffected, except they will all be proportionally lower?..

> this file is processed from a frame size of 524288 samples (~12sec.)
> http://www.esbasel.ch/Downloads/outputtest-vb2.wav

that’s really good, just what i’m looking for! thanks for your help, i’m finding this stuff really interesting to play around with.

#135555
Jul 9, 2008 at 5:24pm

> If you randomise the phase each time you play the complete frame it
> should not pulse any more if you have the ideal windowing. But maybe you
> need a really good random generator, which is the domain of Peter
> Castine’s objects…

one thing i did try was generating 10 (for example) different random versions, then when looping them, randomly choose a different one each time. there was still pulsing, which i guess is because my windowing function isnt right, but could also be because of a poor prng – i’m just using the rand() standard C function

#135556
Jul 9, 2008 at 6:29pm

On 09 Jul 2008, at 19:20, pete wrote:
>
> yes, this sounds much better. how are you looping the result?
> (wouldnt there be a click if you just looped it straight?)

no you don’t need no windowing, just loop the processed buffer –
that’s the cool thing about it. since all the harmonics are integer
multiples of a (very low) fundamental, there can’t be clicks.
at least this is true for the power of 2 buffer length i’m using.
don’t know about fftw – should be the same though.

>
>> if you don’t take the infinity too seriously, you could also use an
>> fft which is even larger than your file, and zero-pad the rest of the
>> frame.
>
> this sounds like a very good idea, so the magnitudes would remain
> unnaffected, except they will all be proportionally lower?..

don’t know exactly what you mean by “porportionally lower”.
magnitudes will be more or less the same, just more…
zero padding is a common trick in dsp to enhance the frequency
resolution.
with larger fft sizes you get more bins over the same frequency range
(0 -> SR),
i.e. a lower fundamental and thus a longer loop if you transform it
back to time.

>
>> this file is processed from a frame size of 524288 samples (~12sec.)
>> http://www.esbasel.ch/Downloads/outputtest-vb2.wav
>
> that’s really good, just what i’m looking for! thanks for your
> help, i’m finding this stuff really interesting to play around with.

fine.
this is a single fft frame transformed back into the time domain.
should be seemlessly “loopable”.

volker.

#135557
Jul 9, 2008 at 7:14pm

On 09 Jul 2008, at 19:01, Stefan Tiedje wrote:
>
> If you randomise the phase each time you play the complete frame it
> should not pulse any more if you have the ideal windowing.

this would require to calculate the ifft in realtime, which for
_large_ fft sizes is not practical.
v

#135558
Jul 10, 2008 at 9:49pm

actually, i’m having trouble replicating your ~12 second version – it comes out like this:

http://www.thirdmeaning.net/misc/outputtest3.wav

as if the phases are lining up a bit at the start and end.

i’m doing this for each bin, does it look right?:

mag = sqrt((fftresult[i][0] * fftresult[i][0]) + (fftresult[i][1] * fftresult[i][1]));
phase = (PI*Random()) – (PI/2.0f);
fftresult[i][0] = mag * (cos(phase));
fftresult[i][1] = mag * (sin(phase));

#135559
Jul 11, 2008 at 1:34pm

> mag = sqrt((fftresult[i][0] * fftresult[i][0]) + (fftresult[i][1] * fftresult[i][1]));
> phase = (PI*Random()) – (PI/2.0f);
> fftresult[i][0] = mag * (cos(phase));
> fftresult[i][1] = mag * (sin(phase));

just in case anyone is interested, it turns out the problem with the above is that phase should be in the range -PI to PI, rather than -PI/2 to PI/2 like i was doing for some reason.

#135560
Jul 11, 2008 at 1:50pm

This is a great thread, I have always wanted to know more
about the nuts and bolts of FFT/IFFT.

Are you guys doing all this in a Max patch or a source code
external? If there is an example patch, can someone please post it?

#135561
Jul 11, 2008 at 2:27pm

#135562
Jul 11, 2008 at 2:40pm

> Are you guys doing all this in a Max patch or a source code
> external? If there is an example patch, can someone please post it?

sorry, i’m doing it in an external – i wouldn’t know where to begin doing it as a patch. the msp fft objects seem to be geared towards “real-time” frequency analysis, by doing partitioned ffts (short-time fourier transform?), rather than letting you move things around in buffers outside of audio time.. if you see what i mean.

source code is here if you want it:

http://www.thirdmeaning.net/misc/staticresynth~.c

it just needs the fftw library (http://www.fftw.org/), and this random number stuff:

http://www.cs.wm.edu/~va/software/park/

#135563
Jul 11, 2008 at 3:14pm

Thanks Peter, I will download fftw and give your source
a try.

#135564
Jul 11, 2008 at 3:23pm

if you’re on windows then i can just give you the compiled object to save you doing it, i can’t compile it for mac though.

#135565
Jul 11, 2008 at 3:24pm

A multiple frame approach using FFTease external resent~ can be heard here:

http://tinyurl.com/6jzu63

These run in real-time on my 2 GHz MacBook at around 20-25% of CPU.

Volker – I’m curious as to how you generated your very nice examples. Since you used a 524288 FFT size, which exceeds the limits of both pfft~ and fft~, did you write your own external, or use a different program than MaxMSP?

Eric

#135566
Jul 11, 2008 at 6:37pm

On 11 Jul 2008, at 17:24, Eric Lyon wrote:
>
> A multiple frame approach using FFTease external resent~ can be
> heard here:
>
> http://tinyurl.com/6jzu63
>
> These run in real-time on my 2 GHz MacBook at around 20-25% of CPU.

resent~ sounds good. have to look into it.

>
> Volker – I’m curious as to how you generated your very nice
> examples. Since you used a 524288 FFT size, which exceeds the
> limits of both pfft~ and fft~, did you write your own external, or
> use a different program than MaxMSP?

ja, fft~/pfft~ won’t do that.

i use a custom external (vb.fftbuf) that performs an FFT/iFFT on the
contents of a buffer~, and did the phase randomization in max.
the external uses apple’s vDSP lib, so there is no windows version.

http://www.esbasel.ch/Downloads/MaxMSP-Objects.htm

the source is available to anybody who is interested (drop me a mail).
but the external itself is pretty trivial.

BUT, i’ve just had a look into jit.fft, which seems to be happy with
large fft sizes (524288 doesn’t seem to be a problem).
i’ll have a go, and see if my poor jitter skills turn up anything
useful…

volker.

#135567
Jul 11, 2008 at 7:08pm

Quote: Eric Lyon wrote on Fri, 11 July 2008 09:24
—————————————————-
> A multiple frame approach using FFTease external resent~ can be heard here:
>
> http://tinyurl.com/6jzu63
>
> These run in real-time on my 2 GHz MacBook at around 20-25% of CPU.
>
> Volker – I’m curious as to how you generated your very nice examples. Since you used a 524288 FFT size, which exceeds the limits of both pfft~ and fft~, did you write your own external, or use a different program than MaxMSP?
>
> Eric
>
>
—————————————————-

Hey Eric, I did not know FFTease could do something like
that. In future releases of FFTease, it would be good to
include example transformations, like the ones we are
doing. They go a long way in conveying to people what the
different externals are capable of. Can you post the patch that
you used to create these?

#135568
Jul 11, 2008 at 8:25pm

Well shut my mouth! There are in fact sound examples…

http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/FFTease/

#135569
Jul 11, 2008 at 10:29pm

>
> BUT, i’ve just had a look into jit.fft, which seems to be happy
> with large fft sizes (524288 doesn’t seem to be a problem).
> i’ll have a go, and see if my poor jitter skills turn up anything
> useful…
>

ok, here is a version that uses jit.fft and kind of works.
seems you have to press “output” twice when one changes the fft size.
at least on my poor ppc laptop.
not so fast…
any “jittery” person tell me, if you find stupid things.
volker.

/* beware of loadbangs */

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P hidden newex 37 106 66 196617 loadmess 18;
#P comment 75 202 100 196617 be wise…;
#P hidden newex 113 126 20 196617 t b;
#P hidden newex 112 147 50 196617 deferlow;
#P comment 36 166 100 196617 set FFT size;
#P comment 263 188 100 196617 < -- start process;
#P hidden newex 263 265 36 196617 r size;
#P hidden message 263 284 79 196617 sizeinsamps $1;
#N vpatcher 10 59 610 459;
#P window setfont “Sans Serif” 9.;
#P newex 62 154 66 196617 sampstoms~;
#P newex 145 96 36 196617 s size;
#P newex 174 149 27 196617 – 1;
#P newex 62 57 91 196617 expr pow(2\,$i1);
#P message 174 181 69 196617 outputlast $1;
#P number 62 104 47 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P inlet 62 37 15 0;
#P outlet 118 184 15 0;
#P outlet 174 231 15 0;
#P connect 2 0 5 0;
#P connect 5 0 3 0;
#P connect 3 0 8 0;
#P connect 8 1 1 0;
#P connect 5 0 7 0;
#P connect 5 0 6 0;
#P connect 6 0 4 0;
#P connect 4 0 0 0;
#P pop;
#P newobj 38 226 57 196617 p calc size;
#N vpatcher 10 59 884 771;
#P window setfont “Sans Serif” 9.;
#N vpatcher 10 59 471 384;
#P window setfont “Sans Serif” 9.;
#P comment 35 92 100 196617 calc magnitude;
#P newex 133 170 79 196617 jit.pack 2;
#P newex 202 134 71 196617 jit.op @op *;
#P newex 133 133 65 196617 jit.op @op *;
#P newex 133 90 81 196617 jit.op @op hypot;
#P inlet 133 51 15 0;
#P inlet 262 51 15 0;
#P inlet 204 51 15 0;
#P inlet 318 51 15 0;
#P outlet 133 232 15 0;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P connect 6 0 8 0;
#P connect 8 0 0 0;
#P connect 3 0 6 1;
#P connect 5 0 7 0;
#P connect 7 0 8 1;
#P connect 2 0 5 1;
#P connect 1 0 7 1;
#P pop;
#P newobj 131 332 68 196617 p polar-form;
#P toggle 457 160 15 0;
#P newex 457 182 27 196617 + 1;
#P window linecount 1;
#P newex 243 238 47 196617 gate 2 2;
#P newex 172 238 47 196617 gate 2 2;
#P window linecount 0;
#N vpatcher 233 283 711 699;
#P outlet 128 299 15 0;
#N comlet imagB;
#P inlet 259 85 15 0;
#N comlet realB;
#P inlet 198 85 15 0;
#N comlet imagA;
#P inlet 122 85 15 0;
#N comlet realA;
#P inlet 42 85 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 0;
#P newex 128 237 53 196617 jit.pack 2;
#P window linecount 1;
#P newex 279 151 71 196617 jit.op @op *;
#P newex 122 151 65 196617 jit.op @op *;
#P newex 198 151 71 196617 jit.op @op *;
#P newex 42 151 65 196617 jit.op @op *;
#P newex 42 196 90 196617 jit.op @op -;
#P newex 198 196 91 196617 jit.op @op +;
#P connect 7 0 2 0;
#P connect 2 0 1 0;
#P connect 9 0 2 1;
#P connect 8 0 4 0;
#P connect 4 0 1 1;
#P connect 1 0 6 0;
#P connect 6 0 11 0;
#P connect 0 0 6 1;
#P connect 10 0 4 1;
#P connect 7 0 3 0;
#P connect 3 0 0 0;
#P connect 10 0 3 1;
#P connect 8 0 5 0;
#P connect 5 0 0 1;
#P connect 9 0 5 1;
#P pop;
#P newobj 209 332 97 196617 p rectangular-form;
#P window linecount 1;
#P comment 351 241 169 196617 generate random values as phases;
#P comment 299 192 100 196617 imaginary part;
#P comment 289 97 259 196617 second plane (imaginary input should be
zero anyway);
#P comment 395 495 160 196617 ifft back to time domain;
#P newex 342 371 36 196617 r size;
#P number 342 393 46 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 342 448 50 196617 dim $1 1;
#P newex 111 56 36 196617 r size;
#P number 111 77 46 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 111 98 50 196617 dim $1 1;
#P newex 615 208 53 196617 t b l;
#P newex 615 230 36 196617 zl reg;
#P newex 380 279 71 196617 jit.op @op sin;
#P newex 305 279 73 196617 jit.op @op cos;
#P newex 615 252 83 196617 jit.op @op atan2;
#N vpatcher 595 216 1180 633;
#P window setfont “Sans Serif” 9.;
#P newex 100 100 50 196617 deferlow;
#P newex 212 31 36 196617 r size;
#P number 212 59 46 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 212 92 50 196617 dim $1 1;
#P user jit.fpsgui 146 168 60 196617 3;
#P newex 185 211 29 196617 * 2.;
#P window linecount 0;
#P newex 56 86 20 196617 t b;
#P inlet 56 63 15 0;
#P outlet 100 322 15 0;
#P window linecount 1;
#P newex 267 129 48 196617 loadbang;
#P button 267 158 15 0;
#P window linecount 0;
#P newex 267 182 73 196617 expr acos(-1);
#P window linecount 1;
#P newex 100 266 63 196617 jit.op @op -;
#P newex 393 234 45 196617 jit.expr;
#P window linecount 0;
#P newex 100 238 65 196617 jit.op @op *;
#P button 169 64 15 0;
#P newex 100 130 128 196617 jit.noise 1 float32 8192 1;
#P connect 9 0 10 0;
#P connect 1 0 16 0;
#P connect 10 0 0 0;
#P connect 13 0 0 0;
#P connect 16 0 0 0;
#P connect 0 0 2 0;
#P connect 2 0 4 0;
#P connect 4 0 8 0;
#P connect 0 0 12 0;
#P connect 5 0 4 1;
#P connect 11 0 2 1;
#P connect 15 0 1 0;
#P connect 5 0 11 0;
#P connect 15 0 14 0;
#P connect 14 0 13 0;
#P connect 7 0 6 0;
#P connect 6 0 5 0;
#P pop;
#P newobj 305 239 41 196617 p noise;
#P newex 209 420 117 196617 jit.op @op * @val 8192;
#P newex 209 533 62 196617 jit.unpack 2;
#P newex 209 490 162 196617 jit.fft 2 float32 8192 1 @inverse;
#B color 5;
#P newex 209 167 153 196617 jit.unpack 2;
#P newex 209 79 53 196617 jit.pack 2;
#P user jit.fpsgui 95 173 60 196617 3;
#P newex 209 134 117 196617 jit.fft 2 float32 8192 1;
#P inlet 209 43 15 0;
#P outlet 209 577 15 0;
#P window linecount 0;
#P comment 250 564 179 196617 disregard imaginary output…;
#P comment 362 421 100 196617 scale before ifft;
#P comment 272 83 145 196617 fake a 2 plane matrix;
#P comment 168 192 100 196617 real part;
#P comment 482 140 100 196617 switch between polar/rectangular
calculation;
#P connect 7 0 8 0;
#P connect 22 0 21 0;
#P connect 21 0 20 0;
#P connect 31 0 35 0;
#P connect 32 0 35 1;
#P connect 16 0 35 2;
#P fasten 33 0 31 0 462 213 177 213;
#P connect 17 0 35 3;
#P connect 6 0 9 0;
#P connect 20 0 7 0;
#P connect 9 0 7 0;
#P connect 7 0 10 0;
#P connect 10 0 31 1;
#P connect 31 1 30 0;
#P connect 30 0 13 0;
#P connect 35 0 13 0;
#P connect 23 0 11 0;
#P connect 13 0 11 0;
#P connect 11 0 12 0;
#P connect 12 0 5 0;
#P connect 32 1 30 1;
#P fasten 33 0 32 0 462 213 248 213;
#P connect 16 0 30 2;
#P connect 10 1 32 1;
#P connect 17 0 30 3;
#P connect 10 1 14 0;
#P connect 14 0 16 0;
#P connect 24 0 13 1;
#P connect 25 0 24 0;
#P connect 24 0 23 0;
#P connect 14 0 17 0;
#P connect 34 0 33 0;
#P connect 19 0 18 0;
#P connect 18 0 15 0;
#P connect 19 1 15 1;
#P pop;
#P newobj 181 284 75 196617 p do_FFT_iFFT;
#P message 202 155 53 196617 readagain;
#P flonum 38 256 51 9 0 0 160 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 900 180 49 196617 set input;
#P message 900 163 55 196617 set output;
#P user led 836 366 17 17 0 150;
#N vpatcher 20 74 420 374;
#P window setfont “Sans Serif” 9.;
#P message 140 99 39 196617 set $1;
#P inlet 140 76 15 0;
#P toggle 52 107 15 0;
#P outlet 52 189 15 0;
#P newex 52 74 35 196617 sel 27;
#P newex 52 46 40 196617 key;
#P connect 0 0 1 0;
#P connect 1 0 3 0;
#P connect 5 0 3 0;
#P connect 3 0 2 0;
#P connect 4 0 5 0;
#P pop;
#P hidden newobj 801 366 33 196617 p key;
#P newex 853 366 30 196617 dac~;
#P number 855 350 27 9 0 0 32 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user gain~ 856 228 24 100 158 0 1.071519 7.94321 10.;
#P newex 940 113 36 196617 r size;
#P newex 856 199 71 196617 index~ output;
#P newex 856 136 94 196617 count~ 0 8192 1 1;
#P hidden newex 741 269 29 196617 t b s;
#P message 723 270 32 196617 clear;
#P message 723 244 55 196617 set output;
#P user waveform~ 361 244 363 137 3 9;
#W mode select;
#W mouseoutput none;
#W clipdraw 1;
#W unit samples;
#W grid 22.675737;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 0;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 146 179 217;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P newex 181 341 89 196617 jit.buffer~ output;
#P message 181 127 30 196617 read;
#P number 38 186 35 9 4 22 67 3 0 0 0 40 204 140 222 222 222 0 0 0;
#P message 223 186 38 196617 output;
#B color 5;
#P hidden newex 733 190 48 196617 loadbang;
#P hidden newex 741 129 29 196617 t b s;
#P message 723 130 32 196617 clear;
#P message 723 104 49 196617 set input;
#P user waveform~ 361 104 363 137 3 9;
#W mode select;
#W mouseoutput none;
#W clipdraw 1;
#W unit samples;
#W grid 22.675737;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 0;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 146 179 217;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P newex 181 225 83 196617 jit.buffer~ input;
#P comment 75 187 100 196617 power of two;
#P comment 94 258 74 196617 size in ms;
#P comment 215 127 100 196617 < -- read a sound;
#P comment 855 100 100 196617 playback…;
#P connect 20 0 18 1;
#P hidden connect 21 0 23 0;
#P hidden connect 21 0 23 1;
#P connect 19 0 21 0;
#P connect 27 0 19 0;
#P connect 26 0 19 0;
#P connect 18 0 19 0;
#P hidden connect 21 1 22 0;
#P hidden connect 25 0 24 0;
#P hidden connect 25 0 23 0;
#P hidden connect 24 0 25 0;
#P hidden connect 16 0 17 0;
#P hidden connect 9 0 17 0;
#P hidden connect 7 0 8 0;
#P hidden connect 9 0 8 0;
#P hidden connect 17 0 15 0;
#P hidden connect 8 0 6 0;
#P hidden connect 36 0 6 0;
#P hidden connect 15 0 14 0;
#P hidden connect 6 0 5 0;
#P hidden connect 33 0 32 0;
#P hidden connect 17 1 13 0;
#P hidden connect 32 0 4 0;
#P hidden connect 32 0 13 0;
#P connect 30 0 13 0;
#P connect 4 0 30 0;
#P hidden connect 31 1 4 0;
#P connect 29 0 4 0;
#P hidden connect 8 1 4 0;
#P hidden connect 12 0 37 0;
#P connect 12 0 4 0;
#P connect 10 0 4 0;
#P hidden connect 37 0 36 0;
#P connect 31 0 28 0;
#P connect 11 0 31 0;
#P hidden connect 39 0 11 0;
#P window clipboard copycount 40;

#135570
Jul 14, 2008 at 7:54am

#135571
Jul 15, 2008 at 1:39pm

On 14 Jul 2008, at 09:54, Stefan Tiedje wrote:
>
> For Max 5 I had to use a size message to a buffer~ object to get
> the output buffer set. Don’t know why…

thanks, stephan.
no max5 here to test. but i guess it’s a bug introduced in 5.
volker.

#135572
Jul 15, 2008 at 5:04pm

#135573
Jul 15, 2008 at 6:58pm

On 15 juil. 08, at 19:04, Stefan Tiedje wrote:

> In another thread it was mentioned, that the sizeinsamps message
> doesn’t work if you don’t specify a size of the jit.buffer~ on
> instatiation. Seems a known issue, easy to work around…

known and already fixed for the next incremental. In the meantime, you
can still use the size message.

Thanks for your patiente.
ej

#135574

You must be logged in to reply to this topic.