Noticeable latency

If the latency is experienced in controller mode, it’s most likely not midi latency but audio monitoring latency and should check ASIO settings on buffer size. If you don’t have an ASIO buffer of 64 samples (3ms) or even 128 samples (6ms), then your audio latency will throw you off because the midi is being received much faster than the audio will be played back. The only case I’d worry about midi latency is if you have multiple midi controllers and USB peripherals clogging up the USB bus. That could include sending audio via USB along with midi peripherals or controller data.

The MPC Live is less like a hardware sampler/drum machine of old, and more like a laptop and interface running a VI, with everything happening in software. So it’s no surprise there’s some latency... I just never imagined there’d be this much. No fx running on it for these tests, it’s literally one pad with a snare sample on it.

I definitely feel the latency... that’s what got me here.

sorry if I wasn’t clear before, but this is on an MPC Live in standalone mode. Latency between striking a pad and sound coming out of an output on the back is 17 ms.

Wormhelmet wrote:If the latency is experienced in controller mode, it’s most likely not midi latency but audio monitoring latency and should check ASIO settings on buffer size. If you don’t have an ASIO buffer of 64 samples (3ms) or even 128 samples (6ms), then your audio latency will throw you off because the midi is being received much faster than the audio will be played back. The only case I’d worry about midi latency is if you have multiple midi controllers and USB peripherals clogging up the USB bus. That could include sending audio via USB along with midi peripherals or controller data.

That’s terrible. Must be a bug because the latency complaints are relatively new unless everyone’s been using their mpc’s after and just didn’t notice

How is sound being monitored in standalone? Is it direct out to mixer and PA? What type mixer and what does other equipment sound like with outputs to mixer and PA system?

Is the latency the same using headphones on the Live?

If any of the audio is running into a computer first I’d suspect the latency lies there. If headphones have latency then a real problem for Akai

In my test setup, its an all analog signal path from MPC (and the microphone I'm recording the pad tap with) to recorder.

No PA, no computers, nothing.

Yes, I feel the latency even over headphones plugged directly into the MPC headphone output.

I'm guessing the latency is caused by buffering necessary for the MPC Live to do all its processing. The MPC Live appears to be a computer in a box running software, and not a "hardware" device as we used to understand them, so some buffering and latency is to be expected. It's just a bit much.

(I used to repair Fairlights, Linns, Emulators etc, so I do have a reasonable grasp of these things)

17ms - That would be a deal breaker for me.

It's irritating, I completely agree. But at the end of the day, all I'm doing is getting notes into the sequencer, which all get quantised, so I can work with it. I'm pretty new to MPCs, so most of my time is spent trying to find my way around the UI rather than actually "playing" it. Now, if I was trying to record a real-time performance on it, and keep the original timing, that'd be a whole other thing...

So, I ended up selling my Live. Between the latency and the (IMO) impenetrable, unintuitive interface I just didn’t feel inspired to play with it. I accept it might have been my lack of patience in learning the Live, but I can’t say I ever had fun using it. Total vibe-killer when you’re always digging thru the manual to work out how to do very basic things.

Ended up getting an MC101 instead. Not as all-powerful as the MPC, but perfect for the quick little production things I do, and super portable. Anything more involved I can program up in a DAW.

Keen to find out if latency has been addressed on the new MPC One. Looks nice. Dedicated function buttons are good. Smaller and lighter is good. So I could be tempted back. But I suspect latency is similar to the Live since it’s still stuffed with effects and synth plug-ins up the wazoo.

I think something was off with your test. Either the sample itself, velocity settings, something. Or perhaps you just had a bad unit. There’s been a lot of tests going over this, and a lot more people would be speaking out at 17ms. There’s also some issue they had to patch where some samples weren’t playing the right attack and they made it so you could go negative.

Show me a proper test measuring time between pad strike and audio coming out of an output, where the latency measures significantly less than 17ms. I haven’t seen one. I’m looking for 5ms or less before I don’t feel latency.

I don’t think there was anything wrong with my test, or the setup of my MPC. Was very carefully done. And I don’t really see why my machine would have been faulty in this way.

It def always felt like there was significant latency whatever program or samples I was working with, which is why I decided to measure it. You really felt it as soon as you tried to play fast patterns in in real time.

Of course, if you’re automatically quantising what you play, then you tend to think you’re a finger-drumming god. You may never notice any latency because it comes back at you perfectly in time (or near as damnit, allowing for jitter)

Also when clocked to external midi clock, the groove lagged WAY behind bar/beat lines, requiring some major clock timing compensation in ProTools - which worked well, but DAWs that don’t have clock timing adjustment (eg Cubase) we’re basically unusable. I now think this wasn’t to do with dodgy clock response on the MPC, but simply the latency between the MPC deciding it should play a sound, and the audio actually coming out of the unit.

No, I can “finger drum” just fine on my unit. I’d have to dig pretty deep but this issue has been explored and even all the testing you mention done. Here’s one post I found, although it’s going to take some time to find more links to the websites and the testing.

Dan from Akai here. So this issue he's talking about has been discovered by a user on gearslutz, and we've been able to reproduce the issue on some units. Indeed it doesn't appear to be all units, which explains why some users see it, but others don't.

there are actually 3 separate issues, which was why it was so hard to chase down. There was a drift over time (3-4 minutes) that reset itself when you hit play, there was a jitter between notes, which I suspect the thread starter is talking about, and an offset that wouldnt remain consistent on start. again, not everyone had these issues, only a select few. The good news is all of these issues are fixable, and have been addressed in the next release, v2.1. it's scheduled to be released soon, probably within the next 7 days.

I'm not talking so much about problems syncing to Midi clock (though playback latency will obviously make that kind of issue worse), or playing the unit via midi. I'm am literally talking about the delay between striking a pad and the sample playing out of the hardware. I haven't yet seen anyone else do the test that I did. Not saying they haven't, but I'm not aware of it.

Why not try repeating my test on your gear to see what latency value you get from your MPC? I would genuinely be interested to see if people are getting better (or heaven forbid, worse) results.

Here's the test:

1) Create a program with no fx running, and one sample (could be anything, but a snare sound seems appropriate) assigned to a pad. No velocity switching, no envelope attack time, nothing funny going on. As simple as possible.

2) Make sure the sample is edited so that the start point is positioned slightly into the start of the sample, clipping off the initial attack, so there's no way there can be any silence at the start of the sample.

3) Put a mic on a stand close to and pointed at the pad that triggers the sample

4) Find a digital stereo recorder, ideally a standalone unit (but you could record to a stereo track on a DAW), and plug the microphone into the L input, and the mono out of the MPC into the right input. Set levels appropriately.

5) Leave the MPC in stop. Don't have a sequence playing. No FX. No synth tracks or anything that would tax the processor. Make it as easy on your MPC as possible.

6) Start recording on your stereo audio recorder. Strike the pad a few times (not too hard!) with a drum stick or something similar to get a nice clean "hit" recording.

7) Load your stereo recording into a DAW and zoom in to look closely at your two waveforms

8 ) The snare sound from the MPC will of course be a little later than the sound of the stick hitting the pad. By looking at the waveform and identifying the start time of each in samples, you can work out the time (in samples) between the start of the stick strike and the start of the MPC sample playback. Divide by 44100 or 48000 or whatever your record sample rate was. That gives you the latency in seconds. If all is well you hopefully have a figure between maybe 0.003 (3ms) and 0.008 (8ms). I was getting more like 0.017 (17ms).

Here's a screenshot of what I recorded back in the summer. Zoomed in on Just one randomly chosen pad-hit:

** can't seem to get embedded images to work, but here's the link - https://ibb.co/r2LTpRq

MPC playback started at 87914
The pad strike started at 87102
Difference is 812 samples
@ 48kHz = 812/48000 = 0.0169 s = 17ms

popelife wrote:I'm not talking so much about problems syncing to Midi clock (though playback latency will obviously make that kind of issue worse), or playing the unit via midi. I'm am literally talking about the delay between striking a pad and the sample playing out of the hardware. I haven't yet seen anyone else do the test that I did. Not saying they haven't, but I'm not aware of it.

Why not try repeating my test on your gear to see what latency value you get from your MPC? I would genuinely be interested to see if people are getting better (or heaven forbid, worse) results.

Here's the test:

1) Create a program with no fx running, and one sample (could be anything, but a snare sound seems appropriate) assigned to a pad. No velocity switching, no envelope attack time, nothing funny going on. As simple as possible.

2) Make sure the sample is edited so that the start point is positioned slightly into the start of the sample, clipping off the initial attack, so there's no way there can be any silence at the start of the sample.

3) Put a mic on a stand close to and pointed at the pad that triggers the sample

4) Find a digital stereo recorder, ideally a standalone unit (but you could record to a stereo track on a DAW), and plug the microphone into the L input, and the mono out of the MPC into the right input. Set levels appropriately.

5) Leave the MPC in stop. Don't have a sequence playing. No FX. No synth tracks or anything that would tax the processor. Make it as easy on your MPC as possible.

6) Start recording on your stereo audio recorder. Strike the pad a few times (not too hard!) with a drum stick or something similar to get a nice clean "hit" recording.

7) Load your stereo recording into a DAW and zoom in to look closely at your two waveforms

The snare sound from the MPC will of course be a little later than the sound of the stick hitting the pad. By looking at the waveform and identifying the start time of each in samples, you can work out the time (in samples) between the start of the stick strike and the start of the MPC sample playback. Divide by 44100 or 48000 or whatever your record sample rate was. That gives you the latency in seconds. If all is well you hopefully have a figure between maybe 0.003 (3ms) and 0.008 (8ms). I was getting more like 0.017 (17ms).

Here's a screenshot of what I recorded back in the summer. Zoomed in on Just one randomly chosen pad-hit:

** can't seem to get embedded images to work, but here's the link - https://ibb.co/r2LTpRq

MPC playback started at 87914
The pad strike started at 87102
Difference is 812 samples
@ 48kHz = 812/48000 = 0.0169 s = 17ms

What operating firmware are using?

My latency issues pretty much went away once I started using firmware 2.5 -2.7

Timing.... jitter seems to be stable on 2.7

He was talking about the offset In The samples like I mentioned In my previous post. This has been gone over quite a bit with more technical people than I. Theres even a website that has everything documented but sifting through to fit that info will take time.

I have never had any latency issues, but I copied that paragraph because he was stating there was issues with SOME units.

The information you’re seeking is out there replicated by many sources.

What operating firmware are using?

My latency issues pretty much went away once I started using firmware 2.5 -2.7

Timing.... jitter seems to be stable on 2.7

I was on v2.5 at the time I did the test.