I’ve just installed Midi Translator Pro v1.9 and I get this warning in the error log on startup. It is a translator triggered by a key event that just resets all global variables to 0. Any idea what it is? It is just working normally when I trigger it.
Hi @wereMole88 , thanks for reporting, and sorry for this problem! This could be a bug.
Can you please post the project file that causes this error?
Thank you very much!
1 Like
Hello Florian,
Sorry I’ve completely forgotten about this issue as I have not worked with Bome since I made the forum post.
Attached my project that causes the error. It appears to originate from a couple of troubleshoot translators that reset global variables on keypress.
My project is under heavy reconstruction so it is not functional in any way 
CMPU-B 21-5-6.bmtp (495.4 KB)
Hi,
I fixed the issue by deleting and then re-creating translator 0.0 and 0.1 so I suspect there was a corrupt save of the project file so the format of the save may have somehow become corrupt. Do you know what version of MT Pro was being used when you last saved the project?
Also, it is not good practice to have multiple translators update the same global variables simultaneously as this could create a race condition.
I suggest a different incoming keystroke be used for an incoming trigger for these two translators. In fact the best practice to avoid contention between translators setting a given global variable is only have one translator to write to a given global variable where many translators can read it. This is not always possible so care must be taken in writing your project file so that the minimum of possible write overlaps can occur.
CMPU-B 21-5-6-sjc.bmtp (475.5 KB)
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
2 Likes
Thanks for the update - I did skip 1.8.4
and possibly 1.8.3 along the road - don’t roast me too hard.
The troubleshooting preset isn’t part of the actual project - its just there to quickly reset parts of the project when I am developing.
This does occur in my project but in a quite different way. Part of the global variables I have divided in sets that are assigned to carry out processes that can be loaded/stored by bitwise operations to set of globals that store the data the processes need as binary arrays. The idea being that processes that aren’t necessary are idling in binary state while active processes are loaded in decimal states to the processors.
This all developed before 1.9 when the amount of globals was still significantly less than now.
I did not realise bome supported looping back with the goto label command - so initially it was all set up with timers. Im now updating it all to do most of the hard work all within the rule sections making it much more all purpose and easy to work on.
I didn’t mean to roast you. I’ve learned some of the same lessons through the school of hard knocks and just trying to ensure you get there a bit easier than I did.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I was kidding - no worries. I appreciate people pointing out stuff like that since it may save me a lot of time figuring it out by myself.
I forgot to add but that giant list of globals I produced within excel to avoid hand typing. Then copypasted to notepad++ and then to bome. Saves a ton of time hand editing such lists. I see no syntax problems bit may that be something involved? Ill try it out -
Yes, I often do the same thing, for large if constructs.
if pp==0 then ga=1
if pp==1 then ga=2
…
Steve
1 Like
Did not manage to resolve the issue yet. I delete the translator and the error is gone. Then I try to rebuild it and it goes okay untill I try to include all variables starting with x:
xa=0
xb=0
xc=0
xd=0
xe=0
xf=0
xg=0
xh=0
xi=0
xj=0
xk=0
xl=0
xm=0
xn=0
xo=0
xp=0
xq=0
xr=0
xs=0
xt=0
xu=0
xv=0
xw=0
xx=0
xy=0
xz=0
x0=0
x1=0
x2=0
x3=0
x4=0
x5=0
x6=0
x7=0
x8=0
x9=0
save/quit and reopen and the x family is gone and replaced by this:
xa=11
including corrupt options on startup. Emptying the translator makes the error persist. Removing it and save/quit/open removes it again.
Tried y and z variables they do not cause the problem. The problem does occur when I just put the x variables in a single translator.
Steve - thanks for the file - I did not initially try this one but see my post below. The ‘x’ family is not included in the file you send me. It gets removed by what I presume is a bug?
excellent, thanks a lot for finding out more about this.
I could narrow it down to this:
xa=0
xb=0
On reload, it’ll become xa=11. I think I know what’s happening: you can also specify numbers using hex notation, like xa=0x7F.
Upon reading such a file, the Rules are following one another, so it will read like this:
xa=0xb=0
And 0xb is hexadecimal for 11.
It’s fun being a detective 
So for now, an easy workaround is to not assign 0, but, for example, another 0 variable. But also to avoid other occurrences of a 0->newline->x.
pp=0
// avoid 0 newline x
pp=pp
xa=pp
xb=pp
(...)
However, the last question is: why do you want to zero out all variables? Upon start of the project, all global variables are guaranteed to be zero. If you want to restart your project at any given time, use the Execute File outgoing action with just the project filename (including .bmtp extension) as filename (no path necessary):
When triggered, the outgoing action will cause a reload of the project file and initialize all global variables to zero.
I’ll report here when this bug is fixed.
Thanks for the solution - will try soon!
The translator is used for troubleshooting the project. When I use Bome’s restart project for some reason it disables one of my E-MU 1x1 MIDI interface and I have to send it a MIDI message to enable it again.
During development this happens a lot - just resetting all variables like that makes it a lot faster to retry whatever I am troubleshooting.
Reset all variables is also a part of my ‘Reset Project’ preset which is part of the project in case something goes wrong or weird during live play. This avoids having to go manually reload the project on my Bomebox.
Ill try to execute file option. Did not use that one yet.
Also would it be a good idea to have ‘restart project’ to a hotkey? Always have to manually navigate to the menu and then click it.
makes sense!
good idea! It’s on the feature request list.
1 Like
thinking of it… that is also a good function as an outgoing action! Then you can probably avoid your variable reset code.
1 Like
Would be welcomed!
Hi, we’ve released 1.9.0 build 1022 which fixes the x-variable bug, and introduces the shortcut Shift+Control+R (Windows) or Shift+Command+R (Mac) for restarting the project.
- download trial version from the product page
- download full version from your account
Thanks for reporting and for suggesting!
2 Likes
Excellent - updating this week!
Just wanted to share this has not been fixed on the BomeBox firmware?
I’m getting corrupt options on the same rules when loading my project on my BB.
You are running firmware 1.5 (2021-05-31 13:31).
Indeed, this x-variable bug is not fixed in BomeBox firmware 1.5 (which was released prior to fixing this bug). Sorry! Will be fixed in the next firmware version.
For now, you can avoid setting x? variables to 0, or use the workaround above.
Yeah it’s no problem - I just put in the old workaround and it works OK 