What is the limit of the BMT devices?

I've found that asking 1024 midi messages from Traktor results in NOT all messages being received.

why so many messages?
this is a typical for giving color to all the pads of the DDJ devices (16 pads x 8 modes x 4 channels x 2 shifts)

Its unclear to me
- if the messages are not all sent by traktor,
- if there is a limit on the BMT1 device

On bome I'm NOT getting this error:
Error(015): MIDI IN buffer overflow (MIDI messages lost).

As such: can I increase the buffer size of the BMT1?
I would like to rule out bome before asking Traktor


Would need to look at your rules for 0.1 where you seem to be getting the problem.

Bome is really fast.  Try looking at "MIDI IN" instead of "Incoming" to see if there is data coming in that doesn't match your incoming condition.

You will always see "MIDI In" but "Incoming" will only be seen if there is a match for your incoming trigger. 

It may also be possible that having logging on may be causing the issue as it requires time to display the messages which may slow things down.


Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

The only time I've ever seen missing incoming is if the incoming trigger is not set correctly.




Sorry I was not clear. I tested without any logging, and the messages to be found only match once in a while;
second, enabling MIDI IN I see a variety of received messages: example 629 / 715 / 560 / 895
I never saw the 1024 messages exactly in MIDI IN

deleting 100 messages at at time to be sent did not fix teh issue. The issue got fixed when I reached 500 messages. At that moment it recived the exact number of messages, to the last digit.
This brings me if there is a limited buffer in the BMT1 device

How are you testing for missing MIDI messages?


Test #1: I’m asking traktor to send 1 bolean + 500 color messages. Results #1: The boolean matches a dedicated rule, and I see 500+1 MIDI_IN messages on the log

Test #2: I’m asking traktor to send 1 bolean + 1000 color messages. Results #1: With logging off, the boolean only randomly matches the dedicated rule. In a lot of cases it doesn’t match. Second, with loggin ON, I see between 600…800 MIDI_IN messages. I never see 1000+1

As such its not clear to me who is at fault: a) traktor sends less than 1001 messages; b) BMT1 device overflows; c) Bome overflows

Yes, I’ll have to use sendmidi or Bome SendSX to flood MT Pro with messages I assume you are talking about note on messages on MIDI CH10 with note 0? If not, please clarify the messages that are getting lost. Do you know the rate the Traktor is sending them?

thanks for making tests to help me.

I've made new simpler attachements to show you the issue.
the TSI just needs to be imported into the (trial) version of traktor.

The test setup is:
a) press CTRL+Q in BOME
b) bome sends ch16.cc.000 to BMT1
c) traktor receives this and executes "send monitor state".
d) This command is supposed to send 1024+1 messages to BMT1:
- all combinations of Ch{1..8}.CC.{0..127}
- one important message to Ch16.cc.001
e) bome receives all mesages, and executes a rule if ch16.cc.001 is seen.

The results are:
- with 500+1 messages, all mesages are received properly
- with 1024+1 messages, not all messages are received properly: the Ch16.cc.001 rule is executed only in some cases; MIDI_IN only sees 600..800 messages each time

Hope this is now more clear






thanks for helping. I’ve made new attachemnets and a simpler explanation below

OK, well I don't have Traktor, however I can certainly blast 1000+ MIDI Messages from a few other tools to see if I can duplicate the issue.

Are you saying MT Pro is not seeing them all? How would you know if you don't have logging on unless you are sending the MIDI messages to a file to evaluate?





I ran two tests.

  1. With Sendmidi.exe (public domain)
  2. With Bome SendSX

In both cases I blasted 1500 MIDI CH15 CC01 value 127 to MT Pro with the log file actually on.

I then copied and pasted the results to the two below files. In both cases I had 1500 lines so I don't see a problem. You can also see the timing of the messages.

I suspect that Traktor cannot keep up on sending so fast if you are not seeing incoming.

In both cases I set incoming as BMT1. Running on a Windows 10 PC.



Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz



We've seen cases in the past where Traktor could not keep up with a fast flow of messages. It doesn't mean that the problem really is on Traktor's side, but it's yet another indication that it could be. We regularly run automated tests with millions of messages in a few seconds, both for MT Pro and the virtual MIDI ports. And if MT Pro cannot keep up and discards MIDI messages, it reports it in the log window or the error log.

Having said that, it is possible to implement data thinning with MT Pro, but it's relatively difficult. The idea is to skip control change messages if there are coming too many at once.

Sorry to be late to respond to this thread.  I believe the problems I have had with data transfer stemmed from the inability of my AKAI APC Mini's not being able to handle the input from BMT.  In my case, the BMT program I wrote generated a lot of traffic back and forth from APC's and BMT, I'm now at a loss to explain exactly why, now that I'm more deeply immersed in playing. Sorry. 

The problem was possibly exacerbated by the fact that I have 8 APC's.