Helix - I/O latency measurements

Indeed.
How do you think an Octavia/Octafuzz works? Does it analyze the input pitch as well?

For an octave, you can use simple techniques like rectification. So simple in fact, that you can do it with analog circuits. That's how octave pedals work. For other intervals, you can't use simple techniques like that and you must track the pitch. That's hard to do in analog. It's much easier in digital, but it means adding latency to track the pitch. That latency is usually somewhere around 10-20 ms, which you'll notice matches what you measured.
 
Whatever this may work like, the latency stays the same, regardless of the input signal.
I tried with: White noise, a 6-voice synth brass chord (extremely critical stuff), a single bass note, a power chord, a 4-voice epiano chord /w vibrato, a minor third with a clean guitar patch. Latency was consistent all throughout.

So?
 
My kitchen sink preset has a stereo send before the IR block for a cab I one day intend to buy, and a stereo return before the final output that pipes in songs and backing tracks that then play through my FRFRs along with my guitar. Are these one way blocks adding any latency?
 
My kitchen sink preset has a stereo send before the IR block for a cab I one day intend to buy, and a stereo return before the final output that pipes in songs and backing tracks that then play through my FRFRs along with my guitar. Are these one way blocks adding any latency?
No, you only add latency when you run your entire guitar signal through a send and a return.
 
Whatever this may work like, the latency stays the same, regardless of the input signal.
I tried with: White noise, a 6-voice synth brass chord (extremely critical stuff), a single bass note, a power chord, a 4-voice epiano chord /w vibrato, a minor third with a clean guitar patch. Latency was consistent all throughout.

So?

Just a guess, but what do repeated notes of different frequencies look like? There might be an initial sampling time at signal onset that is the same for extra fast vs. extra stable, but transitioning between pitches on successive notes might show larger latency offsets.
 
Just a guess, but what do repeated notes of different frequencies look like?

Haven't tried that exactly. Might do so later on - but so far, all the tests I've done seem to indicate that latency isn't changing with (even vastly) different input signals. There's been a few pitched sounds when their initial attacks were hard to decipher because of the way less than shiny quality of the HX Poly Pitch block, but we're perhaps talking 1-5 samples of a possible "grey area" here, accounting for 0.1ms or something.

Fwiw, even if I'm no programmer at all, I still don't completely buy the "each pitch in a chord has to be analyzed" statement.
When you think about traditional pitch shifting, as happening with, say, vinyl records that you speed/slow up/down or samplers, hence as in length and pitch being altered simultaneously, the quality of the pitch shifting itself is quite excellent, just that the tweaked audio is also stretched/squeezed. In my layman book, all it'd take would be a stretching algorithm to be involved simultaneously.
But as said, I have absolutely no idea about programming, I just don't know why pitch analysis would be required on something that is basically just multiplying/dividing frequencies by a fixed amount while as well multiplicating/dividing lengths.
Also, if that would be happening with chords as well, why can't we then as well pitch individual voices within that chord? Should as well be possible then.
 
Whatever this may work like, the latency stays the same, regardless of the input signal.
I tried with: White noise, a 6-voice synth brass chord (extremely critical stuff), a single bass note, a power chord, a 4-voice epiano chord /w vibrato, a minor third with a clean guitar patch. Latency was consistent all throughout.
I tested the virtual capo (default settings) on the fm9 by recording simultaneously a DI track and the output of the pitch block (which was shifting down 2 semitones)
Pitch Latency.jpg


If we zoom in a little we already see that some notes are more aligned than others, for the first note the latency is almost invisible at this zoom level while the third note is visibly late on the second track

Pitch Latency 3.jpg


This is the latency for the first note (180 samples)
Pitch Latency 1 (180 samples).jpg


And this is the latency for the attack of the third note (1470 samples)
Pitch Latency 2 (1470 samples).jpg


So different algorithms can exist
 
Fwiw, even if I'm no programmer at all, I still don't completely buy the "each pitch in a chord has to be analyzed" statement.
When you think about traditional pitch shifting, as happening with, say, vinyl records that you speed/slow up/down or samplers, hence as in length and pitch being altered simultaneously, the quality of the pitch shifting itself is quite excellent, just that the tweaked audio is also stretched/squeezed. In my layman book, all it'd take would be a stretching algorithm to be involved simultaneously.
But as said, I have absolutely no idea about programming, I just don't know why pitch analysis would be required on something that is basically just multiplying/dividing frequencies by a fixed amount while as well multiplicating/dividing lengths.

Pitch shifting means changing the pitch while leaving the duration unchanged. Simply changing the sample rate like you're describing changes the duration (and has a lot of other undesirable artifacts like screwing up the transients), so that's not how pitch shifter effects work. It sounds like you don't believe anybody about this, so I'd suggest you implement a pitch shifter that works the way you describe and see what you think of the results.
 
Haven't tried that exactly. Might do so later on - but so far, all the tests I've done seem to indicate that latency isn't changing with (even vastly) different input signals. There's been a few pitched sounds when their initial attacks were hard to decipher because of the way less than shiny quality of the HX Poly Pitch block, but we're perhaps talking 1-5 samples of a possible "grey area" here, accounting for 0.1ms or something.

Fwiw, even if I'm no programmer at all, I still don't completely buy the "each pitch in a chord has to be analyzed" statement.
When you think about traditional pitch shifting, as happening with, say, vinyl records that you speed/slow up/down or samplers, hence as in length and pitch being altered simultaneously, the quality of the pitch shifting itself is quite excellent, just that the tweaked audio is also stretched/squeezed. In my layman book, all it'd take would be a stretching algorithm to be involved simultaneously.
But as said, I have absolutely no idea about programming, I just don't know why pitch analysis would be required on something that is basically just multiplying/dividing frequencies by a fixed amount while as well multiplicating/dividing lengths.
Also, if that would be happening with chords as well, why can't we then as well pitch individual voices within that chord? Should as well be possible then.
It's explained in the link I shared above why you need some form of pitch/frequency detection even for the most basic mono pitch shifter.
Speeding up or slowing down the audio is the easy part, stretching or squeezing it to not alter the duration is where you need the pitch detection cuz the audio is divided into several splices which crossfade one into each other, and if the frequency with which those splices alternate
is not "in sync" with the note you're playing, there would be a lot of artifacts, similar to a ring modulator.

Actually on the fm9 you can turn off the pitch tracking in the pitch block, hear how that sounds (first with it active and then turned off)
 
Last edited:
If we zoom in a little we already see that some notes are more aligned than others, for the first note the latency is almost invisible at this zoom level while the third note is visibly late on the second track

Quite interesting.

Simply changing the sample rate like you're describing changes the duration

Sure. Which is why the document linked by DLC86 is adressing the duration issue as the very first thing.

so that's not how pitch shifter effects work.

It is apparently how at least some pitch shifters work.
 
Actually on the fm9 you can turn off the pitch tracking in the pitch block, hear how that sounds (first with it active and then turned off)

Depending on the input material, Poly Pitch on the Helix often sounds more like the version without tracking.
 
A test like this was done back in the day on the L6 forum. The results were very similar. I have actually done some light testing with it too, back when I owned mine, again not as thorough, but same conclusion.

If it walks like a duck...
 
Depending on the input material, Poly Pitch on the Helix often sounds more like the version without tracking.
Placement is crucial.

I can also say that much:

When I joined a down-tuned heavy rock band, I kept using the Poly Capo for a month before deciding which strings to use and adjusting my main axes.

Back then, we tuned to C Sharp Standard, these days it's just the usual C Standard.

Since this is the loudest band I've ever been in, the dry guitar strings weren't audible at all in a rehearsal/live setting.

With the Poly Capo as the very first block in the chain, and feeding it a passive but sufficiently healthy/strong humbucker signal, tracking was excellent, the sonic characteristics were surprisingly present (a little was lost along the way, but that's the nature of the effect), and latency wasn't really worth mentioning (I'm no shredder though).

Thus, the HX Poly Pitch algo is top-tier, imho. It could always be improved, but compared to contemporary pedal industry standards it comes out on top:

The Drop is almost as good, but sound preservation is a tiny little bit less, and there's a high-cut. And the EHX Pitch Fork (besides the juicy/lively POG family) sounds too much like a synth.

I have the Drop, Pitch Fork, and POG 2 in my collection as well, so I know them all pretty well.
 
Last edited:
Back
Top