Latency of Pitch Shifter on Petal

I noticed latency and stuttering when using the pitch-shifting feature in @quentopp’s multi-effects example from a thread in this forum last August (Link to that thread in a comment below).

Other users in the thread reported the same issue, so I stripped the code down as much as I could to isolate the problem. My new version removes all the other effects, ignores the controls and LED’s, and only processed the left channel. Here’s the code I’m using:

Even with everything else removed, the latency is still very noticeable, as you can hear in this video:

None of the official examples for the Petal use the pitch-shifter, so I don’t know where else to look. Is this a limitation of the hardware or is there a problem with the code?

Here’s the original thread with the example I started from, and where several other users describe encountering the same latency issue: Basic Multi-Effect Pedal

Pitchshifting algorithm uses 2 interpolated delay lines, so it introduces delay by design. You can change its amount here:

I would expect shorter delay buffer sizes to add more artifacts, but current value is surprisingly big - I think it would give you 340ms latency.

That PitchShifter class would be more usable if it was a template class with delay size specified as parameter - that wouldn’t require editing library sources to change it in your patch.

1 Like

Agreed about making it a template, but for clarity the SHIFT_BUFFER_SIZE sets the maximum buffer size so that the size can be updated dynamically.

I think there are a few other minor issues with the module that still need some fixing as well. So I will make this a template with a much more clear max_size template argument when I get to it.

Maybe it should be keeping current max size (specified as template param), but use a smaller default delay value based on number of milliseconds multiplied by sample rate. This would be more consistent if higher SR is used.

1 Like