Timing/clock bug - Akai's response

I program 16th hihats a lot and when you listen to them solo they are slightly of beat every now and then (randomly). I becomes worse when you record more sounds in the sequence, sounds have a slight delay when a lot of them are played at once.
I wasn't sure if this was because of the sequencer-clock or the sample engine. So i tested it by triggering another drummachine from the MPC and i got the same results, the sounds were not tight.
Then i changed things around and triggered the internal MPC samples from the other drummachine. Now the 16th hihats were tight. So it's clear to me it's not the sample engine that's reacting slow on the triggers but it's the sequencer that's not triggering tight.
This all has nothing to do with Timing Correct cause i have it turned on - 16th and swing is 50%. I use OS 1.05.

It really became clear that the internal sequencer/clock is causing timing problems when i turned on SYNC IN - as a said the MPC sounds were tight when i triggered them from another drummachine but when i switched the MPC's SYNC IN on the sounds triggered from the were not tight anymore. It was playing an empty sequence but it still interfered with the the midi notes coming in from the other drummachine.

Obviously the sequencer engine needs a closer look. I can't say i'm happy with the way Akai is using us customers as Beta testers for months. The machine is on the market for half a year now and things like this should never be an issue, the MPC series are known for their impeccable midi timing...

I mailed Akai this sequencer-timing bug and got this response from their distributor in the UK:

Akai have confirmed this problem.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
When record a lot of MIDI events such as control change in a Seq. and
output MIDI, the sound will be delayed by many MIDI events.
However this situation is unusual operation.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Their engineers are looking into the problem. It will be addressed in the
next OS update.

Its cool that they at least said they would work on it...

while I haven't noticed this issue, the description given...or moreso, the response from akai, doesn't seem to match.

if you solo the 16th notes, is that really excessive midi data? you made no mention of cc messages, no mad pitchbend wiggles or anything that would generate a large volume of midi data.

but by confirming the problem, I have no doubt that the midi management will be getting improved..so I must thank you for taking the time to help the 1000 community.

this did raise an eyebrow for me though. I have been under the impression that early MPC models did not use midi for internal triggering of the built in sampler. I was also under the impression that the 1000 would also be using whatever method the previous mpcs had. If the problem is identical in outboard gear and the internal sounds...I would have to guess (i can't back any of this up...its just word on the street type info) that the internal sounds are triggered via midi.

just thinking , if anyone can correct any misinformation above, please PM me and/ or post it here.

I believe that sounds triggered internally by the MPC's sequencer are triggered by MIDI.

Reasons:

- Cannot assign the same MIDI note to two pads without affecting playback
- In 16 Levels, a MIDI Note Off message stops the playing of all pads sharing the same MIDI note number

The easiest way to test this out is to assign a looping sample on a pad. Then go to 16 levels, hold down one pad, then another, then release either pad. The MIDI Note Off message stops the playback of both samples - they share the same MIDI note number.

First: Good job on contacting Akai with a clear description of the problem, this is far better than everyone SPAMMING them with hate mail. IMHO, that gets nothing done but annoy the sh!t out of Akai, and gives them more mail to sift through to find real problems.

Second: The Sequencer is using MIDI, but in the way that MIDI files operate: by recording MIDI information (note on, note off, CC# sweeps, etc) and time stamping everything into a file using a MIDI related clock (96PPQN in the case of the MPC). However, this does NOT mean that "MIDI" is running through the machine, the way MIDI runs over slow cables from 1 machine to another. It does not pass info over a little midi interface from the sequencer to the sampler. The MPC has 1 processor, so there's no interface to connect 1 thing to another. It's all in 1 place. Kinda the way your Cubase sequencer controls a VST plugin, all iside your PC, running on 1 pentium processor.

Here's a quick lesson in "Hardware": The MPC has 1 single processor, which does most of it's thinking (sampling, sequencing, CF card I/O). The only thing I can tell it doesn't do is the effects...there's a seperate chip for that. Since it has 1 single processor, it has to take all the processing power it has (bandwidth), and time slice it between all it's various tasks. The thing doing this is the actual "Operating System" or OS, equivalent of windows or osx. The rest of the functions, sampling, sequencing, etc, are called tasks. They are like the programs you run inside of windows, or OSX (cubase, MPC1000 editor, etc). Each task get's it's own share of time, and has a priority of when it runs and how often. Audio obviously takes alot more bandwidth, since it's working on audio samples 44,100 times per second. The sequencer is much slower, requiring less bandwidth (only 96PPQN or for a 120BPM beat, about 192 times per second!) Now, if one of these tasks is not coded "friendly", it can hog more time that it's supposed to, meaning the sequencer can get bumped from it's time slice, or get missed all together. This is how the sequencer timing gets sloppy, or notes get missed!!! If akai fixes this problem as described by cowbell, it really may also fix the note dropping problem as well.

Now, just so people get more insight into how these things work, the MPC has to work on audio 44100 times per second. For the operating system, this means it has to switch what it's doing way to often, which wastes bandwidth. So instead, the MPC will work on "blocks" of audio. So instead of doing 1 sample 44100 times per second (ie-sample rate), it'll process 100 samples at the same time, then only do it 441 times per second. These numbers are guesses, but gives you an idea of what's going on inside. This is why if you set the start & end point *really* close together, you can get some weird effects. The MPC grabs the first 100 samples and plays them, and in the process get's confused about where the real end of the sample is. This *could* explain clicks & other problems some people seem to have when looping. The loop point, currently, might be accurate to 100 samples, and you get extra crap in your trim when you don't intend to. I saw a recent post where someone mentioned moving the loop points slightly off, and suddenly the clicks went away...see how it fits together?

"Reasons: - Cannot assign the same MIDI note to two pads without affecting playback
- In 16 Levels, a MIDI Note Off message stops the playing of all pads sharing the same MIDI note number"

This only shows that the sounds in memory may be indexed by midi note numbers, not that they are triggered by midi.

It would not make sense to take a peice of 2001 hardware, mash the data into a 1982 midi protocol, then read that old protocol back into the same 2001 hardware.