Any way to condense this?


I’m currently working on a project using a MidiFighter 64.
The MF64 takes two note messages for each button LED, one on channel 3 for the color, and one on channel 4 for dimming the LED or set blinking/animations.

The color and animation are combined into one variable.
There is one variable for each button to set a new LED state, in this example it is ‘wa’.
There is another variable which stores the current LED state, in this example it is ‘xa’.
The new LED state is compared to the current one to save on MIDI traffic, otherwise the reaction time for the LED’s becomes a bit slow.

Currently, I have it set up like this:


Timer: LED’s - Update All


// oo = Note number for color
// qq = Note number for dimming/animation, which is always 36 notes down from color


// skip outgoing action if LED state is unchanged
if pp==rr then exit rules, skip Outgoing Action

// if LED changed, set current LED state to new state

Raw MIDI: 92 oo uu 93 qq vv

This works perfectly fine, except for the fact that I have to duplicate it for each of the 64 LED’s, which becomes a nightmare if I have to change anything.

Is there a clever way to condense this into a couple rules combined with a repeating timer to iterate through all the LED’s instead of having a translator for each one?

Hi, yes, you can do a repeating timer and use a global variable to iterate through each of the notes. Is there a pattern for the note numbers? If there is, it is better since then you can use this pattern to calculate the current note numbers for the iteration. Of course you would iterate the time 64 times and calculate the current note numbers for each iteration.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:
1 Like

Yes, it’s a continuous range, so the pattern is just +1, 63 times.

How would I set up the timer to iterate through all the variables?
I assume I have to code all of them into the rules, but I can’t think of a simple way to achieve this.
Could you give me an example?

set up a repeating timer and set the starting value in a global variable (say gc) at 64.

As the timer fires


then work with pp to do whatever math you need to determine the channels, notes, and velocities that you want.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:
1 Like

Thanks Steve,

Iterating through all the notes is not a problem, but how do I feed the 128 different variables into the translator? For every button there are 2 distinct variables that I need in the rules.

I can’t think of an obvious way to list these in the rules and pick 2 at a time to feed into another translator. I know I probably need 3 extra variables(1 for the timer and 2 to forward the variables) and some timer logic but I’m having trouble figuring out the rest.

I would do something like this in Python:

variables = [
[wa, xa],
[wb, xb],
# and 62 more of those

for i in range(64):
    do_something(variables[i][0], variables[i][1])

def do_something(var1, var2):
    if var1 == var2:
        #unpack variables and send stuff

How would I achieve this in Midi Translator Pro?


Bome rules is not as fully capable as Python.

You would need to build a construct such as the below. I usually use a spreadsheet to build it and copy and paste as text into rules.


If pp==64 then rr=wa
if pp==64 then ss=xa
if pp==64 then tt=wb
if pp==64 then uu=xb

If pp==63 then rr=wc
if pp==63 then ss=xb
if pp==63 then tt=wd
if pp==63 then uu=xd

And then use rr,ss,tt, and uu to generate your output.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:
1 Like


:thinking: I think I got the idea now.

I can pack everything into the rules of a single translator, including the whole list of variables.
Then I just trigger that translator 64 times with a repeating timer.

Is that correct?

Do so many if statements slow down the code much, or are 64 Goto’s way worse?
Is it wise to split it up into segments for optimization?

Will the velocirators get me?

I doubt if it will slow down very much but if it does, yes you can but statements periodically to jump around sections if it dow

if pp<64 then goto “jump1”

If pp<32 then goto “jump2”

and the put labels throughout. I know it is not pretty but it works. I’m hoping in a future version some of the language constructs will be better and maybe even have things such as arrays, functions, long meaning variable names, and complex IF else OR AND statements.


1 Like

Thanks for helping out, sometimes the solution is simple but I just can’t get to it somehow.

Named variables would be great, my current project also involves the Octatrack MKII, which takes up almost al variables without numbers from g to v.
Together with the MidiFighter 64 I’m close to running out.
Squeezing in the Launchpad Pro is gonna be difficult, especially if I want to use full RGB color.

The thing I miss the most in the rules besides named variables is making a statement like this:

if pp in(ga, gb, gc) then xx=1

That would help out a lot.
But that would already require arrays I guess.

Yes it would. I’ll pass along this request.


1 Like