Eliminating Delay with pfft~ gadget
Hey Everyone –
So I’m new to pitch shifting in max msp. I’m working on pitch shifting a loop pedal for a looped cello piece that I’m working with (recreating cello song by the books). I’m trying to pitch shift the loops that I’m working with but the delay from gadget is causing quite a few problems. I’m wondering if there is a way to get rid of the delay. I’m not sure if the delay is coming from my computer (I have a decently old macbook that runs into problems with maxmsp if i have too many things running) or if the delay is always going to happen with gadget.
Thanks for your help,
It is in the pfft~ docs somewhere: each fft~ must be done on a window of samples,
and no matter what, your pfft~ patch will take that length of time to execute. to shorten this window too much can seriously harm the pitch accuracy of the results, to lengthen it too long makes the delay very "problematic".
So the answer is c)is always going to happen with gadget.
you can delay the input by a delay the length of the fft window: but the live cellist will notice his/her sound being delayed just as much or more than the delays on the pitch shifted sound.
hope this does not ruin your day, :)
Hi Brian, when I first got into pitch shifting I experienced the same issue, and Charlie is right, you can’t get around it using [pfft~] and [gadget]. I think it’s an issue with MSP, in that processes occur at audio rate.
You have a couple of options around this:
Have a look at the phase vocoder by Luke DuBois in the examples/jitter-examples/audio/jitter_pvoc folder in the Max application folder, and even the tutorial on spectral analysis using Jitter by Jean-Francois Charles in the Toolbox (http://cycling74.com/toolbox/charles-spectral-tutorials/ ), thoughto get access to the accompanying article you need some sort of license to view it for free (like a university library license).
You could also look into the FTM toolkit for Max by IRCAM. The benefit of FTM and Jitter is that they can process data faster than audio rate, which I am going to guess is the problem with [pfft~] and [gadget] (but I could be wrong on that).
Pitch shifting using FTM or Jitter requires a knowledge of FFT and spectral analysis, which is a significant task. So perhaps the easiest way to get pitch shifting in Max is to use one of Tristan Jehan’s external objects, particularly the [pitch~] object in conjunction with the [shift~] object. (http://web.media.mit.edu/~tristan/ ).
I’ve had a lot of success with using those two in a pitch shifting scenario. One note of caution though, is I have had the patch crash on me when I’ve tried to experiment with different settings for the typed in arguments, and never have gotten around to addressing what exactly was the problem, so I tend to use the same arguments as the help patch.
Hope this helps,
Thanks guys –
Both of these posts are really helpful. I guess I’ll stop using gadget because of how much difficulty I’ve been having with it. I really need the pitch shifting to be 100% in time for the cellist to play with it. Of course, there are always ways to work around issues like this (in the performance side of things) so I just made enough loop pedals so that I could record the different pitches instead of pitch shifting. However, I’ll go back and experiment with Tristan’s objects when I get the chance. I’ve used analyzer~ before, but I haven’t looked at his other stuff and I think that could definitely help.
I’ll let you know what I find works.
du you need to do it spectrally? you can get decent pitch shift results using time domain techniques and with much less latency for a given amount of artifacts.
i lately use excellent tap.tools object a lot and want to tell everyone about them because i wish i knew about them sooner. the tap.shift~ object is now being used in many places by me.
It’s impossible not to have a delay if you are using an FFT-based spectral analysis. You can try to reduce the window size to reduce the delay. It might be necessary to increase the overlap factor however.
Forums > MaxMSP