Do you mean the MIDI drivers, and that one of them are causing the problem?
I’ve already tested the hardware device individually as mentioned a few comments above 
So you don’t think this can be solved inside BMT?
Yes, MIDI drivers. But maybe I also need to look at your logic as well with your project to see if I can figure out what is going on.
I’ve only seen this a few times and it usually the result of a MIDI loop.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
As you perhaps saw when reviewing the project earlier, the logic of the rules are pretty basic. Also, I would think any loops inside BMT would show up in the log.
I tend to think the problem has to do with garbage midi coming either from the hardware midi devices or caused by Windows 7’s midi handling which is generally crap.
Either way, before troubleshooting the pc running BMT, I’ll test the project on the BomeBox to see if the problem persist, since the project is meant to go on that anyway.
Next, I’ll see if the problem goes away if I exchange the USB connections for good old midi cables.
Thanks a lot so far, Steve
Mathias
SOLVED! (or rather; the problem persists on the pc, but doesn’t appear on the BomeBox)
Indeed, the problem with MIDI in buffer overflow seems connected to my Windows 7 system or perhaps MIDI drivers.
When I run the project on my BomeBox, it does not appear. That’s fine with me, because the project was always intended to run on the BomeBox,
I think Windows 7 is known for bad MIDI implementation, so my guess is that the problem lies here.
Case closed. Thanks a lot for your help and advice, Steve!
Best, Mathias
Well, I’m glad you got it working! I don’t think this is a WIndows 7 issue rather there may be some other MIDI enabled applications or drivers at play here. You might want to look at your process list to see if there are any suspect MIDI applications running in the background that are affecting this issue. With that said, if you are running on the BomeBox and that is where you are intending it to run, maybe leave it for now. The only concern I have is that you might be limited in testing new configurations as you develop them on your WIndows platform.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Agreed, it’s a bit annoying not being able to test properly on Windows before porting to the BomeBox. But I’ll manage and leave the issue alone for now. I’ll be upgrading to Windows 10 soon, so I should test again then, before installing various drivers.
The reason I’m prone to blame Windows 7 is that I have a handful of hardware devices that works on XP and Windows 10, but not Windows 7…
I’ve had a few applications break native MIDI functionality on Windows. CopperLAN comes to mind as it took over everything hence I had to uninstall it. It had a nice concept, however.
Steve
Hi, glad to hear it works (better) on the BomeBox!
Some quick background:
All processing from incoming messages from a given MIDI port is handled sequentially: if you send 8 MIDI messages in response to one incoming MIDI message, then all 8 MIDI messages are sent and only after that, control returns to the incoming “circuit”, waiting for the next incoming MIDI message on that MIDI port. So if sending a MIDI message is slow (or unbuffered), it could take more time than the incoming message queue is filling up. Now it mainly depends on the MIDI driver how fast outgoing messages are processed and if there is buffering, and how much buffering. And how big the incoming message queue is.
Why is MT Pro handling it like that? Every time a message is buffered, it will add very small latency. So MT Pro tries to avoid internal buffering, if it can.
A trick to force the outgoing message into the MT processing queue is to add a delay of 1ms:
But of course, this will add a delay of 1ms to every message.
But in general, there is an architectural problem in MT Pro that sending to 8 ports is not done simultaneously if the message originates from one source. It’s not a problem if the outgoing driver has a small built-in buffer (as in the BomeBox), but if not (as, apparently, in your case), it also means that the 8 outgoing MIDI messages are sent one after another instead of at the same time. We plan to change this behavior in future.
I hope this sheds some light!
1 Like
Thanks, Florian! Interesting, and it all makes sense then, and indeed; adding a 1 ms delay seems to solve the midi in buffer overflow completely!
Solving the problem is great, but understanding it is almost better 