Error Message I haven't seen before

I've been playing successfully without any error conditions for about 3 weeks now, but today did something that resulted in my old nemesis

Error(015): MIDI IN buffer overflow (MIDI messages lost).

but this time it was followed by 150 or so of the following messages: Error(015): engine queue overflow

Can you tell me what causes engine queue overflow.

I was able to recover by disconnecting the APC Mini that seems to have caused the problem, and reconnecting, but, of course, I'd like to be able to avoid error conditions.



Hi Gabriel,

Do you have any idea what you were doing at the time of the error? I assume you are using your modified project with less APC MINI traffic to try and avoid these types of errors. I wonder if we could reproduce a similar error with APC MINI and Ableton (without MT Pro running), to see if we could get Akai’s attention to this issue since we have been able to confirm that every time we see this problem, it has been related to the APC MINI.


Hi Gabriel,

I just ran across this article. Maybe this could be contributing to the issue. I haven’t tested it but just thought this might be another avenue to explore.


Thanks Steve,
I’ll give this a try. I looked at all the USB generic hubs on my system… I think there were 8, and 5 or 6 allowed power down. The root hubs were already set correctly. Let’s see what this does.
As for what I was doing when the APC Mini went “bad”, I don’t know. I was deep into playing and it’s hard to say when it happened.
I’ll let you know how it goes now.

I just now looked at similar settings in the Device Manager under “Human Interface Devices”. There, I also found 7 USB Input Devices. I’m not sure what they are, but they were also set to allow the computer to turn off power to them. I disabled that option here as well as in the Universal Serial Bus controllers section.

I noticed that Ableon Live periodically sends note note messages to the APC Mini so maybe this tends to keep the USB ports alive without having to disable the power down feature.

You could be right about the periodic messages keeping the USB ports alive. I’m almost certain I’ve never had a shutdown when everything is running but idle… say I leave everything on overnight. The problem, though, seems to have been too many note messages being sent to the APC’s.
I’ve disabled the power down features, and since doing it, haven’t had a problem. Fingers crossed!

Crossing mine as well. Maybe I’ll run a test with MT Pro to see if I don’t access the port within 3-4 hours whether an error gets generated when I try again to send another message to the APC MINI.

Hi, I was able to run the below test 2 times testing for 4 hour timeout. It ran successfully twice so I don’t think the problem is related to USB time out.



Hi Steve,
Thanks for going the extra mile. I agree that USB Timeout isn’t the likely culprit, but I think USB power down isn’t explicitly a timeouti ssue. I think it’s meant to keep power on a USB port even if the computer is in sleep mode.
Still, I must be superstitious. I’ll just leave the settings so that USB ports never shut down power. First of all, my laptop is always plugged in. Otherwise, I wouldn’t be able to play for long since all my controllers are USB powered. I think they draw about 2 amps, especially when lots of LEDs are lit. Also, I don’t really see a downside to doing this. If I do use with my laptop with the power disconnected, I’d also have detached all controllers A USB port with nothing attached can’t be drawing much current.
Besides that, I haven’t seen the problem since I disabled USB power down (in addition to thinning out the Midi stream.
You’ll be the first to know, if I see the error messages pop up again.

Only took me 5 minutes to set up the test. I just left my PC on and came back later in the day to check whether the problem occurred. I agree that it is probably to play it safe anyway.

I’m afraid I got the “Error(015): engine queue overflow” again. I’m pretty sure I know know what I was doing at the time; I was moving two volume faders at the same time…kind of see-sawing them slowly. Strangely, I had been doing the same thing for several minutes without a problem, and had done it many times before.

Could you please find out under what circumstances Midi Translator would generate this error message. I don’t think we’ve ever established that.



Hi Gabriel,

Checking with Florian, Do you have fader movement feedback suppressed going back to your APC MINI? That is where we saw the problems before.

both error messages are related. I can only assume it’s the same root cause as in your previous thread:

Have you verified that you’re not sending too much data when moving two faders slowly?

oh, and for the error message: “engine queue overflow” happens when the outgoing actions are slower to process than the influx of incoming actions.

So I would assume if the MIDI port is hung (like before), and error 15 would be the case from both an OS and a MT Pro standpoint. My bet is that MT Pro is just passing through the error code from the OS driver.

I would recommend that there is never any CC feedback going into any of the attached APC MINIs. The controller would have no use of this feedback anyway. An example translator is shown below that would be any MIDI message bound to any APC MINI.

Input (any source) pp qq rr
// Look at high order nibble by shifting it to the right
// Is high order bit a CC message?
if pp!=0xb then exit rules skip outgoing action
// pass through anything else (should be notes only for LED feedback

Output: pp qq rr to APC MINI

I think I’ve solved the problem by being even more severe in limiting the flow of note on/off messages to the APC Mini’s.
I’ll explain, but first, in response to Steve… I have never have sent CC info to the Mini’s. Midi Translator receives CC messages from the Midi’s, and from Live. Sometimes, MT then sends note ons (for LEDs on) or note offs (for LEDs off), but never CC messages.
And in response to Florian’s question, yes.. indeed… I believe it has been when I’ve moved the faders slowly that the problem resurfaces… but probably only at certain speeds of motion.

My solution (hopefully it IS a solution) is NOT to send THIS to an APC in response to each fader increment:
Translator 1:
90 00 00 90 01 00 90 02 00 90 03 00 90 04 00 90 05 00 90 06 00 90 07 00 90 02 01
which turns off 8 LEDs in a column and then turns on the third one.

Instead I start a timer at each increment of the fader. timer delay is 300 ms. The timer is restarted with each increment. So … only if fader movement stops (or is very very slow) does the timer time out. This triggers the output of the 9 translators as below (each with a delay of its own.:
Translator 1: – no delay
90 00 00
Translator 2: – 50 ms delay
90 01 00
Translator 3: – 100 ms delay
90 02 00
Translator 8: – 400 ms delay
90 07 00
Translator 9: – 450 ms delay
90 02 01

I know this is overkill, but it seems to do the trick. I certainly can wait a second for the LED states to change, and I didn’t want to spend yet more time paring down the delay values to see if I could make it happen faster.
An explanation of why I needed this kind of LED control is below, if you’re interested. I’ll leave out much of the detail because it becomes plodding to explain it in depth, though I will do so if someone actually wants it.

In my project, with 8 APC Mini’s, for each Mini, I need to select one LED out of a column of 8 LEDs and turn only this LED on. If one of the other LEDs has previously been lit, I need to turn it off. Since I was nearly out of global variables and didn’t want to do bit mapping. I decided to use brute force and turn off all the LEDs, and then turn on only the one I wanted to light for each Mini. This requires no globals at all.

I think my mistake was to do this by sending out a string of Raw Midi messages for each Mini, turning off 8 LEDs first and then turning on the desired one. That’s 27 bytes. This wouldn’t be a problem if it were only done once, But it is sometimes repeatedly done – 127 times – as a fader moves through its range. And if I move more than one fader at a time it really is a lot of throughput.

My first step was to use a timer to prevent the messages from being sent as often. This was a step in the right direction, but now and again I’d get the error message. I think maybe his happened because I didn’t choose a large enough delay for the timer. And I get the feeling that moving the faders at a certain speed made things worse.

Wow, you would think if the led’s were so sensitive, it would also crash when running Ableton Live. With that said, I don’t think doing anything with faders in Ableton ever updates LED states so maybe it has to do with a combination of fader movement and LED updates at the same time. I wonder if moving faders while changing clips playing (and of course LED updates) could produce this problem. The reason, I’m saying this is that maybe if we could make it fail with Ableton Live, Akaipro would listen better to this problem. Their current position seems to be that the controller was designed for Ableton Live and they cannot guarantee behavior when running with anything else.