FFT Different window type and overlapping

Hi synths,

Is it possible to change FFT’s default window types (use tukey, welch, blackman, etc) or overlapping(use a UGen as an argument) in from the client side using sclang ? Or is this only possible via modifications on the FTT C++ code ? Is there any plugin or quark for that ?



See wintype and hop args

Sorry for the vague question, but I mean changing the window to other any arbitrary type like parzen, welch, blackman, tukey, etc. (It’s easy to create an array of these windows but it’s hard to think about a way to insert them in the FFT…)

By changing the overlapping I mean using a .ar Ugen as a argument.

Not in a straight way I’m afraid.

You could do a granulation, that doesn’t alter much and take different FFT params for each grain. I don’t know though (actually I rather doubt) if you would get very interesting results out from this kind of dynamic change.

1 Like

I see…

@dkmayer do you know if it is possible at least to execute calculations with more than one window ?

For example, I would like to scramble data among 4 windows, or among 8 windows etc…

Is this doable in the SC realtime context?

Sorry, I don’t understand what kind of scrambling you’re imagining.

Supose that my FFT have produced the following magnitude windows:

time window 1 - [ 1,  2,  3,  4,  5 ]
time window 2 - [ 7,  7,  7,  7,  7 ]
time window 3 - [ 8,  9, 10, 11, 12 ]
time window 4 - [ 0,  0,  0,  0,  0 ]

Lets say that I want to scramble data among each 2 time windows for bins 0 and 4, in order to have the following result:

time window 1 - [ 7,  2,  3,  4,  7 ]
time window 2 - [ 1,  7,  7,  7,  5 ]
time window 3 - [ 0,  9, 10, 11,  0 ]
time window 4 - [ 8,  0,  0,  0, 12 ]

Is this doable? I know some PV Ugens that operates on different windows doing specific tasks, but I don’t know how to manage FFT’s data more generaly across the windows… I’ve check pvcalc and pvcollect but they don’t seem to allow this kind of thing…

What you describe would require looking into the future !
It should be possible though with PV_RecordBuf (Josh UGens, SC plugins) where data is stored, but you’d have to fiddle with storage convention. Maybe someone has already done such ?

Freely speculating about it: this could be nice with blocks of bins and blocks of windows, a frequency-differentiated brassage technique. But I’d rather do it with bandsplitting the audio file first and then applying the brassage, splitting could be done with filters or FFT.

I am still learning how real time works…

Just speculating as well, would it be possible to do it at real time if I have a block size of 1024 and FFT windows of 256 ?

I am guessing that because of the PV_MagSmooth which implements a recursive average based on this formula:

PV_MagSmooth - Smooth spectral magnitudes over time

Smooths out the magnitude of FFT bins over time using recursive averaging.
For each bin, the calculation looks like:
mag = (prevmag * factor) + (mag * (1-factor))