buffer read-writing inside pfft~ >>> possible?
I am trying to implement a phase unwrapping algorithm with pfft~. The algorithm itself is quite simple but requires me to access previous unwrapped phase values. It’s not about the phase of the same bin from the previous fft frame but the unwrapped phase of a bin’s direct neighbor from within the same fft frame.
Since signal feedback (like holding the previous unwrapped phase value for one sample with delay~ and feeding it back into the signal calculation) seems to stop the entire msp-chain I tried to implement a buffer~ that gets filled on the output side of the calculation at index x (using poke~) and read out on the input side at index x+1 (using index~). I tried both writing and reading with an index offset. Of course the corresponding buffer reading respective buffer writing then used the current index value.
Still, I am not getting satisfactory results. For example when I delay the algorithm output by 1 sample and substract it from the next algorithm input (which should be the same if the read/write procedure from above works correct) I get nonzero results.
Is what I am trying to do possible at all? Can you write to and read from the same buffer inside one frame (vector size) of pfft~? Are there other solutions? I think I used vectral~ for something similar once but am not so sure about it any more. Would I be better off writing some dedicated external or using good old fft~ instead?
Thanks in advance for any insights!
Here’s a sample:
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 833.3oc2X1rbaBCDG+r8SgFeoyz53hj3CQuzoOGcxzAajioEjX.4FmjI9Yun EnAmZ.gw0M0WPyJKC69S69WK7zzIyVJ2wymg9D5qnISdZ5jIvT5IlTYOYVRv tUwA4vxlsRljvEpYyK+MEemBlOeibabn3cJjZSTNZIG8HOS9450kFnVsIRb2 2x3qTkOOrCdg0bD0yQOfcrzCjhqnaq9SQgvsVt762XWeiVKEJQPBG9kujEED W+KhsIQhXtB7S7KSJ2ppm0pwMIO5Q3lfIKrzy97zo5KyGIGR2DjyQaE2mEjl VDvneJkgRY85hiD7UxsBXwz1gCgUREepdvySe0lcb1PdqwFA+9B+5OPyM6Q3 NxGHVt5njYCYEjENsmMP8FXHSNZHiaIjqltbkpGR4kN3r7n6DEO.zsmBS1lr jmsui3uJv8fAWmtpFn902mDYHuY.NPdTDQvd+ui4CAD4z.zbzr0wx.0IRp1x d5mc1XCxcX++k6bbhDxiCdnnlpypJeFfDLnt551YVk60BYRk+fuGARw48q3P sghMV2vgNP3P+GoxFIB46LO3wVvYKLVWAO4pol4C66GIjxNR5VFw1+ZAIueO xcAgQwLGCXiMAZHoyZE6qFgjrhV0BMpsEBFN6woy5HJ4ZALebHIMXOfJkc1z JavWKr4FCzXvk0QcqwPtZzXVEjojox3tHCEa23.IupLmiSFmyBXNV6s9lzc6 eABsdsJRzsRCsRbAvTYOKswG+yxqDRGIeZgTfCCuI7q9xCPLqm+P7kK2lsp9 gTe1K5k3NjmWvt.UjTzXQ5F1ZrnMQggbQyVvRhBSkQBUkSzxloo9j1kHl3RX ycIZwa+6nad2GTIr8KakuvZjNqtetdAHw+hBPi7IJaX9DA6nQGlBCk3DLFoy p+.D8CP1auLPug4RUYfke+oJX5AZNiCeDCvmtKxKH9z8eze9G4h5SNGnWzBl 7GnnByBTSbA0DBobPaMRm8U6Wc3sWPQEiNo.+laSkbZapXVYgpu0BuiXRIM1 xAqyfjSeghyIEIdv28tgwYvSsLvSGh1nqm14XvUJgVaL1xHiRYcOoyAoVj5V rqsFqpoqomZiubJ4F0IwXDhJLdd5uTdw8vB -----------end_max5_patcher-----------
The problem here is that the dsp is executed in blocks – therefore [index~] reads all of it’s values before the poke object has written any. For what you want to work you’d need a vectorsize of 1 (which you don’t have inside a pfft – it’ll be half the fft size).
I’d say it’d be easier to do what you want in an external – fft~ won’t help here – you’ll end up facing the same problems. I can’t think of a satisfactory way to implement what you want in MSP code alone – as the phase unwrapping that you are doing involves a non-linear part (the round) – that couldn’t be emulated using a filter object (which can sometimes be used for these kinds of feedback applications).
If you really want to do it in MSP alone, you can try going into a [poly~] with a vectorsize of 1 and then your code may well work as is, but don’t expect it to be very efficient…
Thanks for your reply, Alex!
I was planning to develop an external eventually so I think I will take the external route.
I never before developed an external for use in pfft~. Are you – or anyone else – aware of any anomalies or special features in comparison to a "normal" msp external? The only reference I found in the Max SDK is
If I understand things correctly pfft~ always hands over a signal vector which consists of the whole first half of the spectrum as long as the full spectrum flag is not set.
Hm. I s there a way to move this thread into the Dev forum…?
Yes you are right re the signal vector. There aren’t any real differences to be aware of, unless it is important to you to know whether or not you are in a pfft~ in which case you’ll need to check by reading the relevant symbol when your object is instantiated. I can’t remember what it is right now, but I could dig out the details if you really need it. Most of the time it is enough to just assume that the vector size is half the fft size (although in your case I think the actual vector size is irrelevant – it’s just important to know that one vector is one frame of fft data)…
Thanks again Alex
>> I can’t remember what it is right now, but I could dig out the details if you really need it.
That should be
struct t_pfftpub as far as I can see.
Well, I’m still fighting with other implementation parts of my project so I am going to set this particular problem aside for now and give things a try again in due time.
Forums > MaxMSP