Ref wrote: ↑Sat Feb 18, 2017 5:34 pm
But isn't there some relationship between 'i' and 'frequency'?
Otherwise, what does the 'visualizer' show?
Ah, but there is! Or at least, it would be if the fft implementation wouldn't suck.
The way i'd imagine it, is that you give the fourier transform a maximum frequency (a sampling rate of 44.1 kHz, for example), and the number of bins you want to get out of the signal you pass into it... (First one should be the DC component in all cases though, basically the main offset of the signal, which also has a constant 0 imaginary part)
The library used here has one input, a table of samplepoints.
...
If you pass it 1024 smp-s, you get back 1024 bins. (Half of it mirrored on the nyquist frequency (samplingrate / 2), of course, so totally useless from a visualization standpoint)
...
If your sampling rate is anything but 44.1 kHz, then the relationship is messed up, but otherwise, for that exact rate, it works, somehow.
Also, the equation is this: frequency (Hz) = i / (#spectrum (number of bins) / 44100)
At least, iirc that was in the original code example.
Also sorry for my overall tone, it's not the OP whose code i'm mad about, to be clear, but the person who made the lua port of the fft lib, that he uses.
In any case, the fft does give back a table with values relating to frequency ranges, but the partition sizes, count, and the frequency limit is what's inflexible; It's still in the Frequency Domain.
Worth noting that while i do dabble in music, both from a coding and a composing perspective, i don't claim that i understand everything regarding fourier transforms and related stuff; i might be wrong.
Also some disclosure: I use the same p.o.c. lua fft lib in my visualizers as well.