Mooer Pitchbox - 19 msec of latency?

[pipelineaudio]

I've triple checked this now and still getting the same result...I'm splitting a guitar signal with one going direct and one going thru the pitchbox and measuring the difference, same as I always do and getting 19msec latency. Am I doing something crazy wrong or is it possible its actually this much?

 

[GTR37]

I've triple checked this now and still getting the same result...I'm splitting a guitar signal with one going direct and one going thru the pitchbox and measuring the difference, same as I always do and getting 19msec latency. Am I doing something crazy wrong or is it possible its actually this much?

View attachment 8124

Well It’s a Mooer

 

[FractalAudio]

Pitch shifting necessarily has latency. You need a history buffer big enough to contain at least one period at the lowest frequency you want to be able to shift. 19ms isn't bad and corresponds to about 53 Hz. Probably actually around 60 Hz as some of that latency is A/D and D/A conversion time and frame buffering.

If you want a "polyphonic shifter" you need a buffer that is large enough to hold an entire "period" of the waveform. This period, which we define as the maximum autocorrelation time, may be much greater than the period of the lowest note played. I.e., if you play an open E chord the period will usually be much less than 1/82. Some chord shapes result in very long periods, particularly those with dissonant intervals, e.g. major 7.

The shorter the buffer the less latency but the more tremolo effect will be introduced due to imperfect correlation at the splice point. The longer the buffer the less tremolo effect but the greater the latency.

 

[pipelineaudio]

What's the latency on the Digitech Drop?

 

[Lysander]

What's the latency on the Digitech Drop?

I recall reading ~16ms on some forum.

 

[pipelineaudio]

sheesh! I'll just stick with Helix's Simple Pitch. Its not as good on the clean tones, but for distortion I'll live

 

[FractalAudio]

I recall reading ~16ms on some forum.

I doubt that. I remember testing it at one point and it had significantly more latency than the pitch shifter in the Helix, Kemper and our products.

It uses a different approach. Whereas the aforementioned products use a granular approach the Digitech uses a frequency domain approach. This leads to less tremolo effect but increased latency and some strange artifacts on complex chords.

 

[TSJMajesty]

I doubt that. I remember testing it at one point and it had significantly more latency than the pitch shifter in the Helix, Kemper and our products.

It uses a different approach. Whereas the aforementioned products use a granular approach the Digitech uses a frequency domain approach. This leads to less tremolo effect but increased latency and some strange artifacts on complex chords.

So on the Axe Fx, using the VC, the Pitch Tracking where you can set it to Fast or Smooth (or off)..., is that what allows one to decide which tradeoff to accept? Or is it more complex than that?

 

[Lysander]

I doubt that. I remember testing it at one point and it had significantly more latency than the pitch shifter in the Helix, Kemper and our products.

Tried to find the source and, sure enough, Google tells me there's a Reddit post discussing 16ms - which is currently on a private thread, like half the rest of that site

 

[pipelineaudio]

Tried to find the source and, sure enough, Google tells me there's a Reddit post discussing 16ms - which is currently on a private thread, like half the rest of that site

View attachment 8138

thats the one I saw too. I looked at the cached version and it alluded to 16msec

 

[pipelineaudio]

If its even anyone near the Pitchbox's latency, I gotta save some extra hard laughs for the latency purists that freak out about 6 msec RTL on an RME interface

 

[paisleywookiee]

If Mooer’s latency is 19ms, just remember whatever product they stole the code from also has that latency, so you might as well just keep it.

 

[ejecta]

I wonder if any new AI tech will be usable to help with latency of pitch shifting.

 

[Will Chen]

I wonder if any new AI tech will be usable to help with latency of pitch shifting.

Only if it can figure out a way to write the code way more efficiently or make a processor somehow run faster.

 

[paisleywookiee]

I would think that perhaps accuracy would/could be improved, more natural-sounding and less weird artifacts. But at a certain point, it’s physics.

 

[Lysander]

AI hype is a bit like blockchains: whenever someone promises them as a magic solution for anything, just run away.

 

[ejecta]

Only if it can figure out a way to write the code way more efficiently or make a processor somehow run faster.

I’m sure that would help, didn’t think of that. I work in the CG visual arts and there’s a lot happening in the space where the AI can “fill in the blanks” or “look ahead” or “do tedious time consuming building processes very fast” like building CG character rigs or whole miles long landscapes or enabling real-time effects in video creation etc. I am sure audio is a different beast but maybe it can help with latency issues.

 

[ejecta]

AI hype is a bit like blockchains: whenever someone promises them as a magic solution for anything, just run away.

In my line of work it’s isn’t all hype. It’s already being put in the software I use daily and the new tools work great.

 

[FractalAudio]

I doubt AI could do much about latency. The problem with pitch shifting is you have to know what has already been played. You need a history of the audio before you can do anything.

You can improve the quality of pitch shifting dramatically but that comes at the expense of increased latency, usually greatly increased. Melodyne, for example.

Pitch shifting falls into two methods: time domain and frequency domain. In time-domain pitch shifting you buffer up a short history of the audio and play it back either faster or slower depending if you want to shift up or down. You can't start playing back until you have buffered up some audio so you get latency proportional to the buffer size. On average about half the buffer size since you overlap snippets and crossfade.

In frequency domain shifting you take the FFT of the audio, process the FFT and take the inverse. To take the FFT you need a decent size history so, again, you have latency. The most common FFT approach is the phase vocoder. I spent a lot of time working on a phase vocoder pitch shifter and the latency was much worse than time-domain approaches. For any significant shift you need a large analysis window.

 

[Orvillain]

Cliff is right. Latency is effectively a requirement for pitch-shifting algorithms. The more latency you allow, the better your accuracy can be, generally speaking. But you'll never have latency-free pitching shifting. It isn't possible.