MPC 5000 Tap Tempo/Audition Bug

Hi there good ol 5k owners, i had a few crashes and lost some valuable work this week thanks to the following bug:

The 5k freezes when you hit Tap Tempo repeatedly (trying to track down a loop's bpm) while auditioning a sample from the internal HD in the Disk/Load/Listen menu. Steps to be taken:

1. Go to Disk Mode
2. Hit the LOAD button
3. Go to a sample with groove elements on the 5k's internal HD
4.Push and hold the PLAY button, while doing this...tap along the rhythm with Tap Tempo a few bars et voila....it crashes.

The Tap Tempo button keeps on lighting up very nervously and the screen freezes.

Tell me you are joking.

You really expect to be able to stream a sample from the drive and use the tap tempo at the same time?


Please tell me you are joking.

Load the d*mn sample.

This is not a bug.

No dude im not jokin...and no i dont track out a d*mn sample's bpm while streaming it from the HD (on purpose). It happened accidentally. But when i had three freezes in 3 hours that way, i started to trace back my actions, and this is what i came up with.

If ure auditioning samples and u hit the taptempo more than once with lets say your underarm accidentally..it freezes..and gone is your work. And that is a bad thing.

To me it is a bug, because the main reason i mess with mpc's is because they should be more reliable then software sequencers...

Plus it's 2010...lol

I agree. I bought the MPC as a rock solid alternative to sometimes buggy computers for live usage as well. This definitely qualifies as a bug. Yes, the occasion is a rare and weird occurence of events, but in the end it means that broader modules conflict and hang the system. Solving a bug like this could have a positive effect on much more than just this situation.

Damn Akai / Numark, processes should either multithread or be inaccessible under certain circumstances, and if this is not possible they should at least fail gracefully. I'd hate to have something like this happen on stage!!

J26 wrote:No dude im not jokin...and no i dont track out a d*mn sample's bpm while streaming it from the HD (on purpose). It happened accidentally. But when i had three freezes in 3 hours that way, i started to trace back my actions, and this is what i came up with.

If ure auditioning samples and u hit the taptempo more than once with lets say your underarm accidentally..it freezes..and gone is your work. And that is a bad thing.

To me it is a bug, because the main reason i mess with mpc's is because they should be more reliable then software sequencers...

Plus it's 2010...lol

So what do you think the unit is doing when it's auditioning a sample?
It's streaming from the hard drive.
You just need to stop being clumsy if you are bumping the tap tempo button.

donlimpio wrote:I agree. I bought the MPC as a rock solid alternative to sometimes buggy computers for live usage as well. This definitely qualifies as a bug. Yes, the occasion is a rare and weird occurence of events, but in the end it means that broader modules conflict and hang the system. Solving a bug like this could have a positive effect on much more than just this situation.

Damn Akai / Numark, processes should either multithread or be inaccessible under certain circumstances, and if this is not possible they should at least fail gracefully. I'd hate to have something like this happen on stage!!

User error is not a bug.

If you can not for some reason not avoid being clumsy and bumping the tap tempo then that's pretty sad.
However you can always raise the tap rate which makes the button less responsive to clumsy taps.

This is not a bug. If you randomly press and repeat a button on your laptop it's going to react. It's would be a bug if the system crashes when you SUPPOSED to use the tap button.

I'm not going to test it, but does it do the same when auditioning from the ROM or else?

Ow... is auditioning a sample really streaming for the HD? lol...nah dude im not an ass. Plus like i said i can imagine that tapping the button while auditioning could be handy if youre looking for loops to fit a certain bpm (especially when ure doin a remix par example).

It just depends on the workflow of the person behind it. Like i said, its very good workable with this bug/problem (whatever u wanna call it)...it was just f'd up that it could happen. And yes..my macbook reacts too of i randomly hit a button, but it wont freeze.

I agree with the don limpio tho, but too each its own. I believe that if you spend 1500 euros for a supposed to be rock solid machine, this should not and may not happen (especially if you have it to make your living). Besides the problem i mentioned above, this is one of the fastest most fun to work with mpc's i been on. Thanks for the feedback in this thread 5k heads..although some opinions might differ lol

CoinUp! wrote:This is not a bug. If you randomly press and repeat a button on your laptop it's going to react. It's would be a bug if the system crashes when you SUPPOSED to use the tap button.

I'm not going to test it, but does it do the same when auditioning from the ROM or else?

I don't know what kind of laptop you use, but mines doesn't freeze when i stream mp3 and hit a button at the same time. In fact i can push all the buttons as much as i want, whitout my laptop is crashing.
If the system crashes when you suppose to hit the tap button, it's not a bug, but a gay-device. When the system crashes when you hit a certain button combination it's just an ordinary BUG. Because the expensive state of the art device should not crash.

The problem J26 is mentioning is a 100% BUG, because the device shouldn't freeze when i hit any button. It's happend to me as well.. was making a beat, 2hours work.. streaming a sample, accidently hit the tap button, boom everything gone. waste of time.

@ ntalec: You have a point that it's not nescesarry to tap a sample while streaming it (although i can imagine that people would want to do it, personally i love tapping, i do it all the time when i play mp3s on my pc, so why not tapping when streaming? would be a nice function.. than at least i know the tempo before i load it into the memory) but still its not a reason to freeze or crash.. besides, i payed a f***ing amount of money for this device, the damn thing shouldn't freeze or crash, even if i want to hit randomly 1000 buttons repeatedly! It has nothing to do with being clumsy, it can happen to everyone. Also you have no reason for being so rude to other forum people who encounters a bug (or in your opinion doing something wrong), and calling them clumsy. Some people are using this device on a professional level and uses it very intensively. When you are working everyday whit it, sometimes it can happen that by mistake you accidently hit a wrong button. No reason for systemcrash imo. I hope akai solves this dumb bug.

@hubn. I never said anything about crashing.

People spend a shit load of money"" on things. You name it. They all expect something perfect because they payed for it. Computer systems which cost a 'shit load of money" do crash at times, have numerous bugs etc. but, are anything but stable. Yet compare the power of todays computer systems with that of the 5000. Let it marinate..............

Sigh... It boggles my mind how people can say "it's not a bug". What is it then? A feature?

Even if it is very rare, farfetched or might even only originate due to user clumsiness, if an error ensues then it is a bug. Pure and simple. Years of developing code (mostly software in combination with hardware and user input) have taught me that there are two extremes of coding:
1) You code for one single instance of 'perfect user behaviour'. This is fast but leaves little to no room for weird user behaviour or repeated button bashing.
2) You map out a flowchart of every possible step, and chart all possible variables, outcomes etcetera, and construct the paths to follow depending on user input.

The reality is that every project falls in between these two extremes. In the first case 'coloring outside of the lines' triggers errors immediately. In the second case every singly user errors is caught and compensated for. Coding by rule number 2 is virtually impossible for big projects (such as the MPC 5000), and as a programmer you invariably sneak in simplifications where you sort of assume that the user will not do illogical things. This normal and human. But still, leaving open the option for the user to f**k up a system is a bug.

Object Oriented Programming allows (among other things) to split up code into manageable separate modules or objects, each with their own rules, input, behaviour and output. It is wise and often necessary to include error trapping code or gracefull failing in each object - usually this comes down to "Check whether the input falls under predictable and logic. If so, perform a function or return a value, if not exit and/or return a flag that indicates the object could not perform a given task."

Main parts of the machine (that detect user input, control the DSPs, control the HD and the interface) should be coded like this. Most of the time they DO behave admirably in the MPC 5000. In this case a rare combination of user input triggers a freeze. As rare as the occurence is, this means that there is a flaw in a bigger object or module, that could possibly pop up elsewhere.

I'm not saying this is the end of the world, and I don't think this particular event will happen to me. But get real: if a program or application has an error in the code that causes it to 'underfunction', it's a bug.

A tiny and rare one, yes, but a bug nevertheless.

I am a computer engineer and I code for a living. This definitely qualifies as a Bug, ntalec sorry but you are wrong, that's all there is to it.

ritec wrote:I am a computer engineer and I code for a living. This definitely qualifies as a Bug, ntalec sorry but you are wrong, that's all there is to it.

Shouldn't it be qualified as a designer fault? Or are bugs and designer faults both the same?

CoinUp! wrote:

ritec wrote:I am a computer engineer and I code for a living. This definitely qualifies as a Bug, ntalec sorry but you are wrong, that's all there is to it.

Shouldn't it be qualified as a designer fault? Or are bugs and designer faults both the same?

It is neither, you are simply asking the unit to do something outside of it's design parameters.

The Roland MV has a similar aspect and it took Roland quite some time to make people understand that they were causing the problem by asking it to do something it was not intended to do.
Also ritec I really doubt you code for a living maybe a little hobby but not for a living, if so you would have a better understanding.

ok haha I code but not for a living. I still think it is a bug.