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:
LED 1
Incoming
Timer: LED’s - Update All
Rules
// oo = Note number for color
// qq = Note number for dimming/animation, which is always 36 notes down from color
oo=36
qq=oo-36
pp=wa
rr=xa
// skip outgoing action if LED state is unchanged
if pp==rr then exit rules, skip Outgoing Action
uu=pp/128
vv=pp%128
// if LED changed, set current LED state to new state
xa=pp
Outgoing
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: bome@sniz.biz
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?
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:
return
else:
#unpack variables and send stuff
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?
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.
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.
I think I got the idea now.