Div.error at 3000 on MPC 2000. Any help?

I get a Div. Error at 3000 on my MPC 2000. Has anyone experienced this and possible know the cause? Any help would be greatly appreciated.

Are you using an external scsi drive?

Yes. I have pcm adapter for compact flash with 1.72 os.

Does it happen on other external SCSI devices too?

I have not tried another device. Do you think it could just be the SCSCI drive? It only happens after the mpc has been on for a while, so I get to lose all my work....frustrating. I'm using a 32gb SanDisk partitioned in two sections A/B. Thank you for replying to my posts. I appreciate it.

I know I'm not being of much help but when I've got similar issues via SCSI, it pertained more to the type of media I had connected to it.

Do you have any other memory cards you could try with it?

Yes. It doesn't seem to do it with my 1gb sandisk. I'm going to save the sounds to my computer and then try to reformat the disk and see if that's it.

oh shit, i actually know that answer to this!

short answer is you risk Div.error when your envelopes are too long, both decay and attack settings.

long answer. mpc is supposed to be 32 note polyphony, 16 note if all stereo. when the playback settings have very long attack and decay settings AND you have many sounds stacked it will crash the box because eventually you get envelopes without samples, processing a sample that doesn't exist. thus the div.error, you can't divide 0 by anything. it's silly really, they put allocation for the samples but not the envelopes. I have some programming experience I'm confident I could fix the issue, call it an os 2.0 but you can't get the source code so that's not gonna happen.


if you have decay and attack set to 0, there is literally no way you can get a div.error because the number of envelopes will always match the number of samples playing. also if every sample is loop=ON type, div.error is impossible. you can test all this by rapidly retriggering a hi hat sample. extremely rapid note repeat 32/(3) @ 300 BPM. try it. 0attack/0decay will survive. looped sample will survive. 100decay & nonloop will die.

practically the biggest risk for div.error you ever get on the mpc2k is when you want to get creative with hi hat samples, which are short samples and you may be retriggering them fast enough, with to much decay it will generate enough envelopes to crash the machine.


the solution i found is first, just keep all chopped phrases playback settings at attack=0 decay=0. and deal with it. no envelope settings for chopped phrases.
second, all other samples are made into loops. even the one hit drum samples can be loops if you loop the silence afterwords. if all the samples are looped, (with 100 samples of silence afterwords the loop) then div.error is not possible. a loop will always go on long enough for the envelope to close.

hope this helps

Big Ups Harmoncj for dropping knowledge. I use envelopes on ALL of my drums. I loop silence after ever sample I use to prevent the Div Error. I use OS 1.72. although this isn't terribly time consuming, it is still a pain to do. Or worse, after I have spent a few hours recording and trimming drum samples, I lose all my work because I forgot to loop the end.

Vel to Attack and the Decay settings are a necessity to me. And Velocity to Sample Start. Don't even get me started on Filter Envelopes, they niiiiiice. I wish this could be solved so we all could use these amazing envelopes without adding another step to sampling.

Does the XL have this problem?