Real Time Phase Vocoder?

    Oct 06 2013 | 2:14 pm
    Looking at Msp tutorial talking about Phase Vocoder I was wondering if it is possible to make phase vocoding on real-time input like with an Ezadc object and using poke~ instead of record~ . I've just modified the tutorial patch, created 2 pokes~ (one for real, one for imaginary), I've indexed them with a count~ but it really doesn't work, and it's like buffer can't do his job, as it is always deleting his sound and can't go any further from his beginning in the time domain table. Maybe this is due to the nature of real-time or maybe it's just that I'm such an idiot as 2idiotsand1max are?

    • Oct 06 2013 | 5:26 pm
      It's definitely possible. Can you post your patch?
      Part of the overwriting happens because you typically have overlapping ffts with pfft~ and they'll overwrite each other if they're using the same buffer. (You want to use a local buffer~(i.e. name it something like #0_buffer)
    • Oct 06 2013 | 7:44 pm
      Thank you Peter for your answer, so you mean that I'd have to use different buffers? I don't get it. Poke reads from a buffer and index does too from the same one , if I use different names how can they work?
      this is the patch, pretty much the same from the tutorial ( I've just copied what I needed) :
      and this is the inside pfft:
      Thank you very much for your interest!
    • Oct 07 2013 | 1:18 am
      Try this:
      And this for the main patch:
    • Oct 07 2013 | 7:41 pm
      Thank you, I will check it out as soon as possibile !
    • Oct 08 2013 | 9:09 am
      Ok, I've checked and I've got a few ( a lot of...) questions... I send the 2 patches back to you with some comments inside, if you got spare time just look at them!
      here the main patch:
      And here inside the pfft:
    • Oct 08 2013 | 10:15 am
      hey, i do'nt know nothing about fft but why i know is #0 is a randomly generated number that will change each time you load an instance of the bastraction in which there is the 10. This means that the name of buffer will indeed change for each instance. See help for "unique identifier" in chapter "arguments and special character in max" of Max help.
    • Oct 08 2013 | 11:52 am
      Thank you wichug, I actually didn't know, I've checked on buffer's help file but there wasn't anything about. I'm gonna go and have a look. Thank u again
    • Oct 08 2013 | 6:45 pm
      #0 is the way to create abstraction-local names, whether for buffer~, send, receive, send~, receive~, table, etc. It's the functional equivalent of a private variable in some programming languages. (It is visible, though, but you have to know the name)
      You have to put the #0 at the front of the name, e.g. #0name.
      The same thing is true for arguments in abstractions (#1,#2...) when you want to share names between abstractions.
    • Oct 09 2013 | 5:34 pm
      Good questions. Here's my thoughts:
    • Oct 09 2013 | 7:11 pm
      (for reference : i meant not in any helpfile, but the actual max help browser)
    • Oct 09 2013 | 7:25 pm
      Hey Peter, the sah~'s outlet inside the pfft~ isn't connected to anything, yet you say it prevents getting weird combinations of multiple frames. Do some signal objects have effects without beeing connected inside pfft~ world, or is that a forgotten connection ?
    • Oct 09 2013 | 8:26 pm
      @Vichug: Yeah, that should be connected if you want to only change frames at the frame boundary. Without it, you could get data from several frames (especially if your position signal is really noisy). Either could be useful and interesting, but I intended to connect it...
    • Oct 15 2013 | 7:48 am
      Thank you very much for your answers Peter!