I’m looking for advice on how to debug a BMT project that runs well from my PC under Bome MIDI Translator Pro, but fails in unpredictable ways when I move it to my BomeBox.
I have a BMT project file that is around 350K that run my rather complex WindSynth rig. It runs great from my Win10 PC, handling a dozen devices, including two with the same name (and I have to sort out which one is which). Thanks to Bome Network (and a careful naming strategy), I can plug any of those devices into my BomeBox or my PC and the device location is transparent to my BMTP project running on the PC.
However …
When I move the project to the BomeBox to simulate my ‘on-the-road’ scenario, I experience somewhat random failures. Sometimes, the project does not run at all. Sometimes it runs for a while then completely stops. Sometimes, a few rules seem to not function, and some piece of the functionality is ‘missing’ (typically associated with triggers that I set for recurring actions).
I have a PoE power supply to the BomeBox, and it connects to my devices through a powered hub.
Is the current best-practice to sprinkle Log messages throughout my code, turn them on with a global flag, and trace execution in the Bome Network log window?
As you know, in general, translation projects work the same on BomeBox as on the computer.
Yes, that is one technique. Another is to set up certain MIDI messages to go to your PC at strategic times and you can monitor from there. Kind of light different error codes for different conditions. Say, you have it use as an example CC 45 on MIDI CH 8 (or any other CC or channel not otherwise used in your project), and it is value indicates the error code you are sending. I think with the latest BomeBox firmware, however, log messages are sent to the BomeBox log file but I have not tested that yet.
Typically if things don’t quite work, it has to do with timers and global variables which happen asynchronously which if not handled properly can cause a race condition. It is important that you only have a single translator change the value of a global variable and make other translators only read that variable. This used to be hard prior to the new perform action but now you you can pass local variables to perform thereby delegating updating the global variable within a single translator. I feel your pain.
The other problems that I’ve seen have to do with poor WiFi causing missed MIDI messages.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Wow - debugging using MIDI messages - a whole new protocol DOMP - Debugging Over MIDI Protocol. Sounds like it would be overly cryptic … Think I’ll try the Log message route.
So I’ve most likely mistakenly relied on an order-of-execution that happens on the PC that is different (i.e. asynchronous) on the BomeBox. Hmmm. This is gonna take some work …
I’ve got for live broadcasts that I’ll stick with PC for, then we go on the road in the fall - gotta have it straightened out by then …
Even on PC, translator execution can be are asynchronous however the CPU speed on a Computer and BomeBox may not quite match so the timing may be different. This would even be true on 2 separate computers.
I think I’ve seen some discussion from Florian about when translators may execute in parallel but don’t remember whether it is on this forum or in the manual (which sadly I haven’t looked at in some time).
I’ll look around to see if I can find that discussion.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz