Latency of pitch shifting algorithms cage fight

Sascha Franck

Goatlord
Messages
10,647
To get that off the Helix thread:

This is wrong. At the very least, your latency time is dictated by the lowest note you want to support. Because you need at least a full cycle in order to correctly detect the pitch, in order to perform any shifting in the first place.

A low E on bass? 23ms minimum.

This is just wrong. I just transposed an E1 up 2 semitones with the HX Poly Capo and it kicks in at 13ms.
 
You need to read the full sentence in context:
At the very least, your latency time is dictated by the lowest note you want to support.

This is absolutely true. You latency time IS dictated by the lowest note you want to support. There are ways to circumvent it, to mask it, to parallize the processing, in order to improve latency performance. But as a baseline rule, it is absolutely true. You can ask anyone who does serious DSP programming. They will agree. Even if you perform a load of tricks to get the latency down, you're fundamentally still being dictated by the lowest note you want to support.

The word "dictate" does not mean "absolute" - it means it is a strong practical law that constrains what you can achieve, depending on the algorithm you choose, the trade-offs you choose, and ultimately the sound quality and pitch shifting quality you want to achieve.

No amount of CPU horsepower is ever going to change that.

Now I don't know how you measured it. I measured in Helix Native. So you're probably getting extra from the hardware. These are the figures I got:

Helix Poly Capo - 10.4167
Helix Poly Whammy - 9.1667
Helix Poly Pitch - 10.02
Helix Simple Pitch - no latency that I can detect, but EXTREMELY smeared transients.
Helix Twin Harmony - no latency that I can detect, but EXTREMELY smeared transients.
Helix Pitch Whammy - no latency that I can detect, but EXTREMELY smeared transients.
Rubber Band Pitch Shifting Algorithm - 391ms (with Reaper default settings)
Elastique 3.3.3 Pro - no latency that I can detect, but EXTREMELY smeared transients.
Axe FX III Advanced Whammy - 12.15ms (set to notes mode)
Axe FX III Advanced Whammy - 11.05ms (set to chords mode)
Axe FX III Classic Whammy - 29.1875ms (set to notes mode)
Axe FX III Classic Whammy - 29.13ms (set to chords mode)

Axe FX III Virtual Capo - 8.96ms (set to notes mode, tracking adjust at 5.0 - shift at +24)
Axe FX III Virtual Capo - 7.71ms (set to notes mode, tracking adjust at 10.0 - shift at +24)
Axe FX III Virtual Capo - 9.88ms (set to notes mode, tracking adjust at 0.0 - shift at +24)
Axe FX III Virtual Capo - 22.33ms (set to notes mode, tracking adjust at 0.0 - shift at -24)
Soundtoys Little Alter Boy - 1.73ms (sounds awful though)

But you've proven nothing. All you've proven is that the Helix most likely doesn't do full pitch detection for its pitch shifting.

All in all - you're still being ignorant, you don't have the language nor the understanding of DSP to even discuss this. You selectively read what you want to read, you cherry pick, and you made outlandish statements.

Since you want to be so literal and pigheaded, let's track where this all began shall we?

Well, it basically really only depends on CPU power. More juice = less calculation time needed.

If you hadn't have said such a silly and obviously wrong thing, then we wouldn't even be in this pickle that we're in.

I already clarified in the previous discussion; there are multiple ways to approach pitch shifting, that can bring latency down. But in a simple naive implementation, you DO need a full cycle of a note in order to detect its pitch. This is physics. It is not arguable.

Sources:

Seriously, if you cannot accept this truth then I really don't know what else to tell you. I've given you all the knowledge and guidelines for you to educate yourself. The fact you refuse, is just astounding.
 
Last edited:
So:

Helix Poly Capo - 10.4167
Helix Poly Whammy - 9.1667
Helix Poly Pitch - 10.02
Helix Simple Pitch - no latency that I can detect, but EXTREMELY smeared transients.
Helix Twin Harmony - no latency that I can detect, but EXTREMELY smeared transients.
Helix Pitch Whammy - no latency that I can detect, but EXTREMELY smeared transients.
Rubber Band Pitch Shifting Algorithm - 391ms (with Reaper default settings)
Elastique 3.3.3 Pro - no latency that I can detect, but EXTREMELY smeared transients.
Axe FX III Advanced Whammy - 12.15ms (set to notes mode)
Axe FX III Advanced Whammy - 11.05ms (set to chords mode)
Axe FX III Classic Whammy - 29.1875ms (set to notes mode)
Axe FX III Classic Whammy - 29.13ms (set to chords mode)
Axe FX III Virtual Capo - 8.96ms (set to notes mode, tracking adjust at 5.0 - shift at +24)
Axe FX III Virtual Capo - 7.71ms (set to notes mode, tracking adjust at 10.0 - shift at +24)
Axe FX III Virtual Capo - 9.88ms (set to notes mode, tracking adjust at 0.0 - shift at +24)
Axe FX III Virtual Capo - 22.33ms (set to notes mode, tracking adjust at 0.0 - shift at -24)
Soundtoys Little Alter Boy - 1.73ms (sounds awful though)

Most of those meant to be used in realtime contexts don't need those 23ms - which you said would be "needed". How is that?

Oh yes, I know, you were later an coming up with different algorithms. But your entry post was just this: One full cycle of whatever frequency it is would be needed to even perform any pitch shifting. And when I said that wasn't true, you started calling me names pretty much instantly.
Just to come up with these numbers on your own, proving your first statement wrong. Which is all I said.
 
Oh yes, I know, you were later an coming up with different algorithms. But your entry post was just this: One full cycle of whatever frequency it is would be needed to even perform any pitch shifting. And when I said that wasn't true, you started calling me names pretty much instantly.
You're supremely literal, supremely unintelligent, arrogant, ignorant, and a custard gannet.
 
No. As said, I just pitched an E1 sine wave up 2 semitones at 13ms latency.
You're not reading my sentence properly.

The key nuance:
  • “Dictated by” does not mean “absolutely bounded by”,
  • but it DOES mean “the lowest note sets the fundamental analysis window length,”
  • and that baseline window length drives your minimum possible latency,
  • even if you apply algorithmic tricks to hide it, parallelize around it, or approximate pitch early.

This is standard DSP knowledge and is taught in every pitch-detection course.
 
Well, it basically really only depends on CPU power. More juice = less calculation time needed.

^ This is absolutely wrong.


Well, it basically really only depends on CPU power. More juice = less calculation time needed.

^ This is absolutely wrong too.

Well, it basically really only depends on CPU power. More juice = less calculation time needed.

^ Yeah, and this.

Well, it basically really only depends on CPU power. More juice = less calculation time needed.

^ Yep, you guessed it. This too.

This is an absolute statement. No way around it.
No it isn't. You just don't understand English well enough to know that dictate does not mean what you think it does.

I'm done with this now. I fully realise that debating you on this topic - which you are ill equiped to do - is a complete waste of my time, and actually, discussing anything with you is a complete waste of anyone's time. @LP59 is absolutely correct. Ignore list time.
 
It’s why pitch to MIDI is always shittier (unfortunately) on lower strings. You’ve gotta do a full cycle for it to determine the pitch, and the lower strings are slower. Nothing but physics hold back the Fishman Triple Play.
 
It’s why pitch to MIDI is always shittier (unfortunately) on lower strings. You’ve gotta do a full cycle for it to determine the pitch, and the lower strings are slower. Nothing but physics hold back the Fishman Triple Play.

Sure, but that's because it has to be converted to MIDI. For that to work, pitch analysis is a must. For static pitch shifting, it's not.
 
It’s why pitch to MIDI is always shittier (unfortunately) on lower strings. You’ve gotta do a full cycle for it to determine the pitch, and the lower strings are slower. Nothing but physics hold back the Fishman Triple Play.
Correct.

When pitch algorithms are faster than that fundamental detection rate (as determined by the lowest note supported) then quite simply, they are not doing full pitch detection. A lot of the newer algorithms basically make educated guesses about what the pitch is going to be, before the information is fully calculated.

What people often misunderstand is that pitch shifting is not the same thing as pitch detection, and many “zero latency” shifters simply avoid pitch detection and use phase-vocoder resampling, granular shifting, or formant-broken crossfades - all of which produce artifacts (poor transient response being one of them)

I already said in the thread that there were ways to change pitch without pitch detection - any sampler that allows you to play a sample across the keyboard does it. Resampling. It is pretty much latency free. But it also isn't the highest quality pitch shifting you can get; it depends on how good the interpolation method is, and even that is dictated by the lowest and highest notes you want to support, because of aliasing concerns.

My statement is absolutely true. His statement was not.

Wrapping clever tricks around pitch detection algorithms does not disprove the truism. It is absolutely true, and every single academic source you read on the subject will emphasize this point. Mr. Encore Fois Graschen refuses to read and educate himself.
 
No one does it well enough, not Eventide, Digitech, EHX, Fractal, or Line 6. It all sounds shit to me.

I absolutely agree. Especially once you play something that is more than a 2 part chord. For some riffing, it works kinda ok-ishly here and there, but it already starts to fail at triads and gets downright horrible once there's 4-part chords involved, even if you use plain sine waves (which can usually be shifted rather well).
 
Your first statement was complete bollocks. You just don't need to analyze pitches to do pitch shifting. That's just nonsense. And as said, that's all I refered to.
You really don't English very well do you?

This is what you said:
Well, it basically really only depends on CPU power. More juice = less calculation time needed.

That quite literally says nothing about the technique used to do the pitch shifting. All it asserts - 1000% incorrectly btw - is that the more CPU power you have for your algorithm, the less calculation time for the algorithm to run. The implication being that you think latency is a result of not enough CPU power. And it simply isn't.

Right. Really done now! Enjoy the loneliness!
 
This is what you said:
Well, it basically really only depends on CPU power. More juice = less calculation time needed.

I know what I said. You could've refered to it and call me an idiot. I even could've considered that as being one option.
But instead you've chosen to come up with an even more idiotic "explanation" of how pitch shifting would work. And when you then got called out on that nonsense, you went all boo-hoo and started calling me names.
That's all.
 
This thread is
Legendary GIF by Giphy QA
Martin Scorsese Cinema GIF
 
Back
Top