FFT Phase Vocoder crackling

hi! thank you :D

that's right, modded the ezfft till it became an almost new thing (called it vfft and made a pitchshifter with it), the 3 things i wanted to change is: variable blocksize, variable overlap and reduced latency - it's all done on event-(instead if audio) base. i'm glad not to really know how reaktor processes this stuff...:D, what i assume is that it can destabilize it

first i indeed used voices for the streams but then it all went into a single event-based machine

the time-scaling stuff can be imagined as something working in parallel independently on all fft-bins, on a single sinewave like oscillator so to say, on a single bin it first calculates a frequency by taking the phase difference of 2 blocks and then run the new oscillators with this frequency - in this unaltered form it produces lots of timesmearing, but this can sound very interesting

funny you say that, i've built stuff with your vfft architecture that fed into event tables (so presumabely not threadsafe lol) and then across multi instruments with different voice counts and then ultimately even fed <i>back</i> into the original core cell and never really run into problems.

anyway, i ended up pretty much fully groking what the event based fft was doing (at least in principle), but the multivoice thing still interests me. it seems without voice management in core you would have to export the streams to primary to deal with that?

Were wrong, there is a timestretcher with (interacting) voices

thing on the window functions on fft with ifft applications, is that in contrast to analysis only stuff they get applied twice, so in total the square gets applied on a neutral (even bypassed) fft, i found nothing to read about this

the thing is, in this case on overlap 2 the Hann and Hamming window don't sum up to 1 anymore like they do in their original non-squared form, the result is a tremolo / ringmod-like artifact it needs a minimum overlap of i think 3 but for sure 4, on windowfunctions with higher terms (Blackman-Harris) it even gets worse

The ezfft uses some hacked window to sum up to 1, i think it's square root of Hann (sqrt(.5*(1-cos (2*pi*t))), t=0..1)

Just to clarify what you were explaining

With two parallel channels, you need the sqrt(hann) to avoid the warbling modulation effect:

With four channels, you can use straight hann:

With two channels, using the square root window makes a significant difference. With four channels, once the levels are matched, the difference is not easily perceptible, although the two versions do not null.

haha great stuff guys. you know, its interesting, for analyis/partial tracking stuff i usually use a gaussian window but some stuff requires flattening it out until its basically a square window. it seems to have a lowpassing effect, as in the partials will remain stable longer... sort of almost the opposite of what i'd expect

what exactly is meant by summing up to 1? i could wager a guess but i feel it would probably be wrong... (maybe unity gain between the windowed section and the raw chunk of audio... ?🤔)

also, what would be the disadvantage of not having this property?

this is an attempt to visualize this: it's overlap 4 and a narrow and a wide Gaussian window, the blue line is the sum, this is what the overall signal gets multiplied with

with overlap 2 the ripple gets stronger

the sound is somewhere between tremolo and ringmodulation. i'll see if i can make a demo to simulate this

but i have to say that the ripple is really low on overlap4/wide, so Gauss could work even on a fft->ifft combo