MPC1000 Crash on SysEx playback

Hey, now it's my turn to report strange goings on:

Following on from http://www.mpc-forums.com/viewtopic.php?p=114520 , I thought I should practice what I'm preaching, and try my own SysEx recording and playback.

- I recorded some SysEx from my Kawai K5000S: 4 x patches + 1 x Multi, the basics I need for full 4-part multi-timbral operation with all patch data in the MPC1000. The recording seemed to go OK, with the SysEx events looking the right size (sez the manual) and the data looks valid.
- The patches are ~2800 bytes each, about 1 second of MIDI time each* , the Multi was ~112 bytes. (That's normal for K5000S, it has a lot of parameters.
- Each event looks valid, and manually sending from Step Edit works, I tried the first one.
- So I realigned them on bar boundaries in a 5-bar sequence as a first test: 1, 2, 3, 4, 5 , set tempo to 60bpm.
When I hit play, the MPC1000 locks up solid at 1:00:00. It looks like the first SysEx is getting out, but no more. This was repeatable, even after restarting the MPC1000 (I saved the Sequence first).

More investigation is required (MIDI-OX etc). And I'll try playing them even slower, even though I'm allowing 4 seconds each (1 bar @ 60bpm), so I'm not flooding the MIDI Out buffer ...

Next, I'll try moving the events off the bar boundaries, put them deeper into the bar. And try the short SysEx earlier, see if size is a factor.

It's not just the MPC1000 either - thread http://www.mpc-forums.com/viewtopic.php?p=116384 seems to talk about it happening on the MPC2000XL.

* MIDI Time: about 1 second per 2500 bytes of SysEx, 10K = 4 seconds. (I can explain if you really want the geek stuff here...)



PS: note how:
- I'm describing what is happening, and what I am doing. Not panicing, saying "it don't work, what now?"
- I'm determined to get to the bottom of this, work around it if I have to.
- I'm not dissing the MPC1000 as junk. (It might even be my mistake, early days yet.) I'm prepared to work at this relationship..!

Instead of putting all in one sequence, try putting each string in their own sequence and use song mode to chain them together. Just another testing method.

I would be surprised that it has problems since I have done tons of work with sysex on the MPC series.

Also, check for midi loops. As a safeguard you should be able to disconnect the MPC Midi In since you should not need to receive data for the test.

mpc3000 wrote:Instead of putting all in one sequence, try putting each string in their own sequence and use song mode to chain them together. Just another testing method.

Thanks - will try that too. I didn't get any time to test last night. I forgot to say I ruled out MIDI Loops straight away, went down to just one cable.

An update for those interested:

First of all, it's not locking up totally: wait long enough, and it comes back. Here's a list of the SysEx blocks I'm sending, with the time the MPC locks up for after it's sent.

Expected delay: 1 bar @ 30bpm = 8 seconds
# Size Delay (secs)
1 112 8.000
2 2768 123.237
3 2854 130.989
4 1070 18.670
5 2854 130.989

Total time: nearly 7 minutes, during which the MPC1000 was locked and unresponsive. I originally thought it had locked up totally.

(I used MIDI-OX to capture the dumps with timestamps: all the SysEx is valid and does its job on the K5000S.)

So, the problem is linked to the size of the SysEx, but it's not that simple: I successfully saved and sent a 18K "All" dump from my Korg DL8000R without the same problem. That worked as in the previous thread: the MPC stalls for a few seconds but then comes back in sync. I would never normally do this big a dump when working, individual DL8000R patches are only about 200 bytes.

If anyone is interested in trying the guilty SysEX: http://stereoroid.com/sounds/mpc1000/K5KPatches.SEQ
You don't need to attach any MIDI device to test this dump, it happens regardless.

It is really not a sysex issue but rather a SEQ capacity limitation for the MPC1000. The MPC1000 processor chokes on the sheer size of the sysex data.

The problem youu experienced can be re-created without sysex:
1) Program a series of 1/32 notes across 2 bars.
2) Copy this track 31 times for a total of 32 tracks of 32nd notes.
3) The MPC will play fine with amount of data.
4) Copy a track 3-4 more times.
5) Playing now will cause the MPC to stutter and hesitate.
6) This was on OS 1.04

It does not matter of they are midi tracks or program tracks (rules out that it is strictly a midi processing issue). This shows that the capacity of a single sequence is about 2000 notes. Of course you can use multiple sequences for additional capacity.

The same happens on the MPC2k series (I've done this same test before), but I forget exactly what the threshold was.

I will try to contact Akai to get the exact limitations of a SEQ since I did not see it in the specs.

After some more investigating, it would be more accurate to say that the limitation is not the total number of events, but rather the event density.

I just created a 8 bar sequence of 64 tracks of 8th notes for a total of 4096 events and that plays OK. I am not certain at what quantified time the density is based on (bar, quarter note, etc). I will do some more testing and post my findings.

I had it choke a little (coupla seconds) on a sequence with a single 18K dump, which I can understand, as per the previous thread - but these hangs for 2 minutes each time I send a 2.8K dump are a whole different ballgame. And it's only during playback, not if I send that SysEx out manually in Step Edit.

Thanks for the assist: the reason I didn't try this sooner is that I don't truly need this facility myself, really, I'm looking at the problems in the other thread. The K5000S saves patches to floppy, and my other devices use much smaller SysEx dumps for patches. The K5000S SysEx is an extreme case, because it's a hideously complex synth at the base programming level, but with some simpler editing screens. I don't really expect the MPC to handle all that smoothly and do everything else it does...

"but these hangs for 2 minutes each time I send a 2.8K dump are a whole different ballgame"

Not really. The limitation is moving data from sequence buffer to the out processing buffer (not the official terms), so it makes sense that the MPC has to take small chunks of this large data set one at a time, process it, and move to the next set. This time is processor intensive so the MPC looks like it is stalling but is actually busy working.

Sysex is the most densely packed data for a sequencer and thus readily shows this effect. Note data can be used to replicate the same issue, but is less densely packed. From I can determine, the limitation on processing is about 300 notes per second (which is a lot). The effect is not linear, so as you pack more data into a narrow time frame the stall becomes increasingly larger.

I get that, I meant "it's far more serious a problem", not that there's a different principle involved. You have to admit it's strange that a 18k SysEx plays back relatively OK, while a 2.8K dump does not, and there's no difference in density. Nor should there be a "train wreck" where new data comes in before the old has left the buffer (I left more-than-sufficient time between the dumps.)
I imagine a fix might involve better handshaking, so that the data flow is stopped before the buffer gets into an abnormal state (my terminology). After all, I'm talking about a 2-minute hang after playback of SysEx that should take ~ 1 second at MIDI rates, so I think "abnormal" is a good word to use here.

Can you post this 18k Sysex SEQ file for testing?

I'm afraid not, I didn't keep it, I just discarded that one when I saw it worked, I was more concerned with the smaller ones that didn't work. I won't get a chance to do that for almost 2 weeks, I'm about to go away on vacation...