buffer read-writing inside pfft~ >>> possible?
Hi
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:
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...
Alex
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 struct t_pfftpub.
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.