I wonder if you can spot the reasons why the attached project won’t run properly on my Bomebox when it works fine on the PC.
It’s a pretty ambitious (many translators and rules) project that allows me to route midi messages from channel 1-16 to any or all of the 16 channels. See this video for demonstration: Dropbox - IMG_0430.mov - Simplify your life
The project is made up of three elements/presets:
a) Init
programs the Beatstep as required by the GUI
resets variables and sets default midi channel rooting
b) Beatstep GUI
represents the routing settings as they are (with LEDs)
carry out changes to routing settings according to pads being pressed
c) Route the midi messages between channels
reads the routing settings and send out incoming midi messages on the designated channels
The project has run smoothly on the Bomebox in a more basic version which was only able to process midi channel 1-8, and this current iteration works fine on the pc, but it doesn’t function properly on the Bomebox that it’s supposed to run on.
Any suggestions/troubleshooting is greatly appreciated!
Well I’m not sure how you have mapped your variables for determining channel mapping. I assume you are using gc-gj for this but not sure on how your logic works on whether to send or not to send. I assume these are some sort of bitmap where 1 bit represents the source channel and 16 other bits represent the legal destination channels. Is this correct? In this case an example would be only take input for MIDI CH 1 and allow sending to MIDI CH 1,3,6,7,11,14, and 15.
Binary is 0001 0110 0100 0110 0101
If this is not how it works, please explain.
Also I notices that A LOT of translators update the global variable “zz”. This is generally a no-no since sometimes translators happen in parallel and you could get the wrong value when reading it back. Multiple translators may be trying to update zz and the same time which would put it in an unstable unknown state.
It would be better to only have on translator to handle all updates for global variables and many translators that can read them. I typically use local variables within the translator, copying from the global variable and then only have one translator update the global variable at the end of processing.
Also , you have most translators that map all inputs to all outputs which can create a lot of MIDI traffic. Best practice is to reduce to only the MIDI devices you want. With that said, if you are careful with your logic in rules, maybe this is not an issue for you. You will always still be triggering a lot of translators so it could be quite a load on the system but at least the outgoing messages should be somewhat restricted by your rules. You might want to put “Stop Processing” on the beatstep translators so that they don’t also trigger some of your channelizer rules.
Finally, I find it best to document my rules for all global variables in one location. As much as I think I can remember what they are for, often times, I go back months later and forget and have to figure it out all over again. It is also a good practice so that you don’t inadvertently re-use a global variable that is already in use.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Thanks! I’m impressed you can make sense of the project
I actually thought zz WAS a local variable, but I see in the manual that it isn’t. Dough! That’s a thing to fix, and it’s simple enough to do. Perhaps with a search & replace in a text editor?
Except for the Beatstep communication, all messages should be sent to all devices, that’s one of the purposes of the project.
Only the 6 beatstep translators and 2 init translators are/should be changing global variables. The rest 500+ only reads them.
The usage of global variables is documented in the attached image. If bit 0 of gc is 1 then forward from midi messages on channel 1 to channel 1. If bit 31 of gf is 1 forward midi messages on channel 8 to channel 16. If bit is 0 don’t forward midi messages on related channels.
As mentioned, this project works just fine on the PC, but doesn’t work on the Bomebox. Could it be too heavy for the Bomebox?
Yes this is a problem. You can try global search and replace in a text editor but be sure to save a backup copy as especially with rules format that MT Pro uses, it could mess things up. In general, it should be OK since the variable you replace it with would be a 2 letter variable. Of course, you can’t use the same local variable that you are using in the existing translator, so picking the replacement is critical and you only have 10 local variables, some of which are being used.
My log was not on so thanks for the chart. I’ll see if there is a better way.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
zz is “only” used in preset 2 and 3, and it can safely be replaced by rr. Now I just need the best way to replace them, because that’s 500+ translators…
However, I have tested the original version in various configurations, and it seems that other problems than the zz variable are causing the project to fail on the bomebox. Because the project won’t execute on the Bomebox even when the translators containing the zz variable are disabled (disabled the preset those translators belong to).
It seems this problem is related to the init and gui presets:
init was triggered by preset activation, which should be project opening instead.
the bomebox fires midi messages at the beatstep faster than the PC, so it must be slowed down on the bomebox or the beatstep and/or the bomebox output fails.
By tweaking those two parameters, I have now made the project run (GUI only). However, the slowing down causes an annoying latency. This can probably be overcome by tweaking the specified delay.
So things are going the right way! Solutions are showing themselves.
I would still love to know a smart method to replace those 6000 instances of zz with rr, so I don’t have to do it manually!
(Maybe AutoHotkey or a similar app can help…)
I just opened it in EditPlus and did a global search and replace from ‘zz’ to ‘rr’.
Then saved the file. Then I opened it up with MT Pro and changed something so I could resave it with the signature, otherwise BomeBox would not run it.
Indeed, for action on preset enable, it must start out disabled. I usually have project start run an ‘Init’ timer and then have another set of translators with incoming trigger of ‘Init’ where I have various outgoing actions.
Interesting. Maybe needs some delays on the outgoing actions. I hope not as this would be 6000 translators you would have to add the delays to.
I’m working on a version with only about 40 translators which might help once the current Beta gets released. I’m hoping the next release will be sometime soon.
If interested, I can ask if we can put you on the beta program and send you a link to it.
BTW the first problem reported had to do with incorrect signing. If you have a full licensed copy of MT Pro, just make a change within MT Pro and the save it so that MTPro will re-sign the project for you. Then it should run on BomeBox.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Thanks. I got the project to run on the Bomebox now. I think the main problem was the Beatstep being overloaded with midi messages. I solved this with a few delays, not a big deal since the Beatstep is only involved as a GUI, so it’s not a general bottleneck.
However, although I only had time for brief testing, the project is not functioning great. It could again be an overload problem, since 500+ translators in parallel are processing incoming midi. Probably not a very efficient setup.
I suspect the project needs a thorough optimization, such as minimization of the number of active translators and eliminating non-essential processing.
I’m definitely interested in joining the beta team! I’ve spent quite a lot of time in BMT Pro the last few years. I mainly use the scripts on my BomeBox.
