Midi Engine Queue overflow

I think these are the words I'm seeing in an error message from MT very occasionally. The words may be slightly different. Though it's occasional, once it happens, every message sent to MT generates this message and everything slows down to a snails pace.

I'm thinking a strategy I had for preventing Live from attempting to switch back and forth repeatedly, trying to show the waveform of of clips when I move several volume fader at a time may be to blame.

I'll give a brief description of the strategy below, but it's not really important at this point to evaluate it. I'm just wondering if it is potentially causing the Midi Engine Overflow.

My question is this: If I send out approximately 3000 Kill Timer events as a result of a single fader moving through it's entire range - and, I surmise, 3000 more for each fader I move simultaneously, during which time, any several timers may be started and stopped 3000 times - is this bound to cause a Midi Engine Overflow.

Below is a sketch of the strategy I use. I can provide more details and the thinking behind the strategy, but it's probably not necessary to delve into that to give me the answer to the question above.

Since I actively request Live to show the waveform for the clip having its volume changed, I thought a clever idea might be to trigger the request with a timer... one timer on each track.

Step 1: Start the timer if a vol fader moves. Delay = 100ms

Step 2: Send out kill timers for all timers, whether or not they've been started (since I don't know which timers have been started. These Kill Timer commands are executed immediately.

Step 3. Finally, the timer(s) that have delayed elapse and the waveform is displayed in response.



Hi, again leave it to Gabriel to test the limits of Bome, Ableton Live, the computer, etc.

I believe from a Bome perspective, killing timers will not cause a MIDI Engine Overflow as there is no MIDI in the timers themselves.

I think you want to kill timers as step 1 and the start your fader timer as step 2. Otherwise, your kill timer will also kill the timer you just started. I might be wrong, however if your start timer is delayed for 100ms because when the kill message comes, the timer will not yet exist.

I’m not sure how much workload 3000 kill timers actually put on your PC though and am also not sure how Ableton Live handles the incoming workload of quickly switching between waveform displays.

I’m thinking the MIDI engine overflow messages more likely how to do certain MIDI message coming back from live if it is also sending messages in response to waveform switches.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist


Hi Gabriel,

I discussed with Florian and he feels 3000×8 timer kills at once could cause this problem.
Is there a way you can only kill the timers you know you’ve started?

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

Hi Steve,

Thanks for following through with Florian about the kill timers and Midi Engine overflow. I believe I even understated what’s happening. For each increment (0-127) of each fader move, a kill timer message is sent out for each track. That’s 20 kill timers per increment x 127 = 2540 kill timers for a full range movement of a fader. I often move 4 faders at a time. So the max number of kill timers sent out would be over 10,000. Of course this happens over a period of time (the time it takes to sweep the faders) and it’s not often that I’d have 4 faders at full volume and then sweep them to 0 volume rapidly… but something close to that happens sometimes.

I’m not sure if I ever caught the incident exactly at the time it happens, so I can’t be sure that I’m even on the right track, but I think i am.

What I’ve done is to abandon this strategy, which is meant to show the waveform for a clip when I change its volume. This way I can visualize where i am in the clip. But I don’t often really need this feedback. Of course i usually discern this info by ear. So I decided that when I need to see the waveform, I will push a button which calls for the waveform to be displayed. No timers necessary because fader movement no longer is linked to waveform display.

It’s reassuring to know that the problem could have been caused by my original strategy because it was pretty gratifying to have the waveforms appear without my direct intervention. I’m sorry to let it go, but, actually – it’ll be ok.

Thanks again,


Thanks Gabriel!

Too bad you are out of global variables that you could use to determine if a timer was running or not. If you did that, you would know which timers to kill and when to skip outgoing action.


I could still do that, I suppose, since I’m running two instances of MT, but sending stuff back and forth between the two is a bit clunky, and, well.. I’m not really that upset about losing the automatic waveform display. It still gets automatically updated each time the fader first leaves value zero (I can send a single request out to show waveform in that case). Also the waveform displays when I first launch a clip with a button. So the only time I have to manually update the clip display is when I move a fader from one non-zero value to another and I need to see where I am in a lengthy clip. I move the volume faders most often just to ID the active track so that I can make changes to plug-ins that are specifically in one track, etc.

Hi Gabriel,
have you ever tested the limits of the BMT virtual devices?