I have implemented rubberband (v3) as a Max/MSP external, and I think it works really well. As with any realtime use of the phase vocoder, latency is an issue.
I recently discovered the Sliding Window DFT, which generates the DFT sample by sample (basically, a hop size of 1).
This has the advantage of distributing the CPU needed to generate the DFT and iDFT over more time as samples arrive, rather than running the full FFT when sufficient samples have accumulated. The Sliding Window DFT can also reduce startup latency (papers I have read suggest useful DFT output is available after about 1/3 of the DFT size has been sampled).
Running the phase vocoder to shift the pitch at every sample would probably be excessive without parallel processing (although it might obviate the need for some of the phase coherence calculations), but it should be possible to generate output from the iDFT at shorter intervals, depending on CPU.
I guess my question is whether this would be a reasonable direction to investigate?
I have implemented rubberband (v3) as a Max/MSP external, and I think it works really well. As with any realtime use of the phase vocoder, latency is an issue.
I recently discovered the Sliding Window DFT, which generates the DFT sample by sample (basically, a hop size of 1). This has the advantage of distributing the CPU needed to generate the DFT and iDFT over more time as samples arrive, rather than running the full FFT when sufficient samples have accumulated. The Sliding Window DFT can also reduce startup latency (papers I have read suggest useful DFT output is available after about 1/3 of the DFT size has been sampled).
Running the phase vocoder to shift the pitch at every sample would probably be excessive without parallel processing (although it might obviate the need for some of the phase coherence calculations), but it should be possible to generate output from the iDFT at shorter intervals, depending on CPU.
I guess my question is whether this would be a reasonable direction to investigate?
Thanks