Cheng Chien-Wen

I am trying to understand the MSP tutorial patch about FFT. But it seems to me that the last example in the manual using frameaccum~ and framedelta~ does not clearly explain why and when they should be used inside PFFT~.

However, all the other patches dealing with convolution rarely use frameaccum~, phasewrap~ and framedelta~.

Could anyone explain to me a little bit ?

Are there other examples that use frameaccum~, phasewrap~ and framedelta~ ?

I would like see more examples so as to know when they should be used. If there is any better way or principle to uderstand it or to memorize it, please also let me know. Sometimes it is really hard for a musician to understand "abstract" math and physics.

PS: If you could, please also explain when index~ may be used in Pfft~ patch.

I am trying to understand the MSP tutorial patch about FFT. But it seems to me that the last example in the manual using frameaccum~ and framedelta~ does not clearly explain why and when they should be used inside PFFT~. 

Could anyone explain to me a little bit ?
Are there other examples that use frameaccum~, phasewrap~ and framedelta~ ?

PS: If you could, please also explain when index~ may be used in Pfft~ patch.  

frameaccum-and-framedelta-in-pfft

because convolution doesn't need phase diff/accum. this is typically 

needed in a phase-vocoder e.g., where you want to record spectral 

data and manipulate the playback speed. to get the correct phases for 

resynthesis you would have to record the phase differences (using 

framedelta~) and, while playing back at desired speed, accumulate 

these differences (frameaccum~) before taking the inverse fft.

BUT, in the spec-delay example which has been posted to the list 

shortly, the diff/accum part is actually not needed and imho should 

better be left out. frameaccum~ will (naturally) suffer from round 

off errors pretty soon and will result in increasingly wrong phase 

values, which in turn leads to blurry transients in your soundimage.

because convolution doesn't need phase diff/accum. this is typically  
needed in a phase-vocoder e.g., where you want to record spectral  
data and manipulate the playback speed. to get the correct phases for  
resynthesis you would have to record the phase differences (using  
framedelta~) and, while playing back at desired speed, accumulate  
these differences (frameaccum~) before taking the inverse fft.

BUT, in the spec-delay example which has been posted to the list  
shortly, the diff/accum part is actually not needed and imho should  
better be left out. frameaccum~ will (naturally) suffer from round  
off errors pretty soon and will result in increasingly wrong phase  
values, which in turn leads to blurry transients in your soundimage.

Quote: vb wrote on Thu, 29 June 2006 04:51

> BUT, in the spec-delay example which has been posted to the list 

> shortly, the diff/accum part is actually not needed and imho should 

> better be left out. frameaccum~ will (naturally) suffer from round 

> off errors pretty soon and will result in increasingly wrong phase 

> values, which in turn leads to blurry transients in your soundimage.

I agree that the phase wrapping is not necessary in ALL cases in a spectral delay (I haven't look at the example in question though so read on to find out when it is). If you miss it out you should also store cartesian values in your buffer and forget about conversion to polar co-ordinates at all because the trig is really expensive to do this. In all my spectral work I try to avoid using polar values for this reason. So far it has always been possible.

So, i said not in all cases - the reason for this is that for fixed delay this works correctly (and arguably more accurately), but not for variable delays (where NOT accumulating will not sound smooth because the phases will not be read from consecutive frames in the buffer as the delay changes so the resultant phase differences will not make sense). In this case it is technically possible to phase accumulate using cartesian geometry (using complex multiplies and divides) which is cheaper. This is hard to do in msp code however. I have made an external that does this (actually for my spectral delay - so i have tried all these different options in practice) - I may post it to the share site soon if I can find time to neaten it up and port to UB.

To summarise - if you want a fixed delay lose the trig and forget about accumulating. If it needs to vary over time then the accumulation will sound much smoother whilst the delay is changing.

> BUT, in the spec-delay example which has been posted to the list  
> shortly, the diff/accum part is actually not needed and imho should  
> better be left out. frameaccum~ will (naturally) suffer from round  
> off errors pretty soon and will result in increasingly wrong phase  
> values, which in turn leads to blurry transients in your soundimage.

> ... I have made an external that does this (actually for my 

> spectral delay - so i have tried all these different options in 

> practice) - I may post it to the share site soon if I can find time 

yes, please do so. good examples of spectral processing are always 

> To summarise - if you want a fixed delay lose the trig and forget 

> about accumulating. If it needs to vary over time then the 

> accumulation will sound much smoother whilst the delay is changing.

hey, that's true. quickly testing this, i found that while changing 

delay times (i.e. jumping around in time...) will always lead to some 

sort of discontinuities, it does sound a little smoother using 

accumulated phase differences than the actual phase values.

however, thinking about that blury sound, where the accumulation 

drifts more and more, gives me the creeps, can't help it...

> ... I have made an external that does this (actually for my  
> spectral delay - so i have tried all these different options in  
> practice) - I may post it to the share site soon if I can find time  
> to neaten it up and port to UB.

yes, please do so. good examples of spectral processing are always  
welcome.

> To summarise - if you want a fixed delay lose the trig and forget  
> about accumulating. If it needs to vary over time then the  
> accumulation will sound much smoother whilst the delay is changing.

hey, that's true. quickly testing this, i found that while changing  
delay times (i.e. jumping around in time...) will always lead to some  
sort of discontinuities, it does sound a little smoother using  
accumulated phase differences than the actual phase values.
thanks for pointing this out.
however, thinking about that blury sound, where the accumulation  
drifts more and more, gives me the creeps, can't help it...
greetings,
volker.

frameaccum~ and framedelta~ in Pfft ?