18: Phase Vocoder (part 1), C++ Real-Time Audio Programming with Bela

Lecture 18 of C++ Real-Time Audio Programming with Bela. This is the first of a three-part series on the phase vocoder, a powerful tool for manipulating audio in the frequency domain. This lecture covers the overlap-add technique of block-based processing.
In this lecture:
Section 1: Block-based processing 0:00
Section 2: Input and output 6:28
Section 3: Overlap-add 12:23
Section 4: Multi-threaded implementation 31:11
Example code and companion materials:
github.com/BelaPlatform/bela-...
This course is a deep dive into how Bela processes data, and how to implement real-time audio and interaction. If you want to learn or improve your skills with C++ and audio programming, this is a great way to start!
Bela is the open-source platform for creating beautiful interaction. If you’d like to get a Bela system to follow along with these lectures, visit shop.bela.io. Use promo code CREATEATHOME for £10 off Bela and Bela Mini Starter Kits.
Music by Vula Viel (vulaviel.com).

[@michelthegreatable]

I've been looking for a good explanation of phase vocoder for months, thank you so much!

[@stevebaines57]

Excellent as always. I think it is worth being clear that the additional latency we add to gOutputBufferWritePointer doesn't need to be an entire hop, as was stated in the video. We need to add enough latency for the FFT thread to be able to finish its task, and that isn't related to the hop value. With the current code, 16 samples seems to be plenty, giving 'int gOutputBufferWritePointer = gHopSize + 16;' This knocks 5.5ms off the latency.

[@apm414]

Good idea! Adding one hop size is the minimum to ensure that you can use all the available CPU, but you're right that if your code reliability and consistently uses less than that, you could trim down the latency. Probably never lower than one audio block size, however, since the background thread won't even start running until render() has finished.

[@applepie182]

great tutorial! Any hints on what to modify in the reading / overlap-add operation for the case of the time stretching algorithm? I got the part with the phase calculation down, however, the way to read and delete samples from the outputBuffer I think needs to change when the analysisHopSize is different than the syntehsisHopSize... Any ideas ??

[@nathanruiz3424]

Please make part 2! I need your help!

[@apm414]

Part 2 is now up: kzbin.info/www/bejne/aHbWl59uqtxgaLc

[@Mc-vd4bw]

Maybe someone has a simple vocoder written in juce?

[@jacobpenn2266]

where part 2 at : )

[@apm414]

Coming soon -- most likely next week!

[@yf668]

@@apm414 This tutorial is so good! Will part 2 come out this month?

[@apm414]

@@yf668 Thanks! Part 2 is coming tomorrow. There will be a part 3 too. :)

[@apm414]

Here's part 2: kzbin.info/www/bejne/aHbWl59uqtxgaLc

[@michaelliuzzi]

I don't see why the latency is the fftsize. Should the latency not be fftsize-hopsize? For instance, in our example, we have 256 samples available. Our fftsize is 1024. That means we will have a 768 samples of zero, followed by 256 samples of whatever gplayer.process() returns.