Fft in pure data

Wildo

Hi everybody!

I am trying to construct a patch that would do the fft analysis of a waveform. So far i have made the patch as follows:

then in the sub patch:

[block size 512]

the problem that i am having is just a visual one. I cant seem to get any read outs on the hann window in the main patch. Any suggestions where i am going wrong?

atarikai

At a glance, it look like you're writing to a table called $0-magnitude instead of the $0hann.. So you would need to put the $0-magnitude table in the main patch to see what it's ploting...

Wildo

hehe got it! I completely spaced for some reason when I was writing this. I looked at it more closely and realised that the hann window function was set to receive but nothing was sending to it. I fixed those bugs and now it is working and outputting to the graphs.

Samuel

Hey Wildo

Now that the patch works, could you attach it please?

Thanks

Wildo

Here it is!

http://www.pdpatchrepo.info/hurleur/Screen_shot_2011-06-10_at_18.47.46.png

gerard

Hi Everybody

I have a question about the patch from the audio browser example I03.resynthesis.pd

how and where I should enter IN to patch < recive eg. from pix blob data > to change the parameters tab Gain ?, mean manipulates the sound in the patch by number random box.

does anyone help me?

THX

tedmoore

Could someone point me to (or provide me with) a good description of why [fft] results need to be squared, added, and square-rooted. I understand the concept of what [fft] is doing but that part of the math I don't get. Why doesn't the [fft] object do that automatically? Is there a reason why one would use [fft] without these calculations? Also, why does it need to be renormalized after the [rfft]? Why doesn't [rfft] do that automatically?

I've had fun playing around with filtering white noise with [fft] but I prefer to understand it!

Thank you!

Maelstorm

Sure. It's really about dealing with complex numbers.

The outputs of [fft~] are the real and imaginary parts of the spectrum. It is the complex number in cartesian form.

z = x + jy

Cartesian math is less computationally expensive, but it doesn't necessarily give you the information you're looking for on its own. Converting to polar form can give more intuitive information. Polar form looks like this:

z = A*e^(jθ)

Here, A is the magnitude (or amplitude) and θ is the angle (or phase). Converting from polar to cartesian is pretty straight forward:

A*e^(jθ) -> A*cos(θ) + j*A*sin(θ)

Going the other way is trickier. The whole "squared, added, and square-rooted" thing is to find A. The way it works is by plotting the cartesian form as a point on the cartesian plane, so that the real part is the x-axis and the imaginary part is the y-axis. The distance between the origin and that point is A, and finding that distance is a matter solving that Pythagorean theorem for right triangles that we all thought was useless in high school:

A^2 = x^2 + y^2

I assume it doesn't do that stuff automatically because it keeps it more general and less computationally expensive. You don't have to go through square roots and atan2 (which is needed find the phase) by sticking to cartesian form. And [rfft~] doesn't normalize automatically because normalization is window-dependent.