frameaccum~ and framedelta~ in Pfft ?

Jun 29, 2006 at 8:44am

frameaccum~ and framedelta~ in Pfft ?

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.

Thank you very much.

Chien-Wen

#26619
Jun 29, 2006 at 10:51am

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.

hth,
volker.

http://www.esbasel.ch

#79873
Jun 29, 2006 at 1:40pm

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.

Regards,

Alex

#79874
Jun 29, 2006 at 4:18pm

hi alex,

> … 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.

http://www.esbasel.ch

#79875

You must be logged in to reply to this topic.