How many local variables again...?

Hey Steve

Sorry - more stupid questions. heh I'm confused on how many local variables there are in MTPro. I count 10: oo, pp, qq, rr, ss, tt, uu, vv, ww, xx

So, I just need a few more and was searching around the forum to get a handle on the proper syntax/concepts to 'do a thing' and I ran across:

" There are 20 available for each incoming event. " - Your Post on https://www.bomeloft.com/support/kb/im-running-out-of-global-variables-but-need-quite-a-few-more-maybe-20

I'm missing 10 variables in my understanding. I think if I ask about these and there *are* more than 10 local variables then I can save myself from having to learn something new to 'do this thing I need to do'.  :)

Local variables– 10 – oo, pp, qq, rr, ss, tt, uu ,vv ,ww, xx

Global variables - 360 – starting with g-n and y-z – 10 first letters – 36 ending letters a-z 0-9

ga-gz g0-g9

ha-gz h0-h9

…

za-zz z0-z9

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

20 was a typo in my original post your referenced. I can’t edit the post but I added a comment to correct this.

I have a spreadsheet for all my Globals. 🙂 Not just Globals that I use (because: all of them), but I like to use ones that relate to what kind of values they store. Like: HA-HD are the 4 states for the Controller LEDs and HW-HZ are the CC#’s that get sent to the device when I operate the 4 Controller buttons. All things for these types are all H, and then the same ‘mask’ is used for J, M, & N. G prefaced Globals are typically system wide and shared between the applicable Presets/Translators. This way, I get less confused. heh Okay, then that means I have to use a DO…WHILE/FOR…NEXT loop if I want to avoid using Globals when a Local would do.

Another thing I do with local variables, some times I can use them as temporary variable within a translator and then re-use them again later when I’m done with them the first time. I usually set up a convention that rr is a temporary (disposable) variable. That way it is easier for me to review my code to see what is happening.

So for local variable my conventions are to have some of them as “disposable” and others “non-disposable”

Since two translators that have the same incoming trigger share the same local variables, you need to be careful that future translators don’t need them but I make it a general programming rule to try to not share local variables between translators that have the same incoming trigger. (but you can if you want)

I gave up on trying to give the letters meaning. I just put everything I use in my “Init Global Variables” translator and usually in alphabetical order. I then copy and paste that into a text editor while I’m working on the project, showing the text editor in a different window.

DO… WHILE FOR..NEXT are not Bome constructs but you can use goto and label.

I try to even avoid that and end up using “skip next rule” or “skip next 2 rules” whenever possible. It can be dangerous using to many goto’s cause it is too easy get yourself into an infinite loop.

For iterative output, not planned but gc generaly becomes my iteration counter.

I usually start assigning globals starting with ga and working my way down, For things that are like items but on different layers (using presets) I typically use 0-9 as last letters to keep them straight (ie g0-9 for layer 1 h0-h9 for layer 2 etc)

Thanks Steve! I need to re-think my local variable usage, perhaps. Or at least the way I have it in my head. heh

I actually have a working script for ‘these things I’m trying to do’ but I’m working on streamlining it and making it easier to understand/edit at a later date when I haven’t been thinking/working on it for awhile.

Honestly what works best for my brain is trying to get as much that has to basically do the same thing into the same Translator. Then I can print it out in HUGE fonts and post them on the studio walls with any notes! LOL

My stuff isn’t complex.
I’m just an idiot. LOL

I’m confused on doing DO–WHILE:

I have an incoming trigger: basically any Note Off in Note Range (so, any 87 pp qq where pp is in my 16 note grid).
Because: reasons, I determine row (0, 1, 2, 3) and column (also 0, 1, 2, 3). Only dealing with one column at a time, because there’s other logic for Rules on other columns, just dealing with Column 0 at this point.

So basically I’m looking at pp which is the Incoming Note #, vv = Row # (used for toggling the on/off bit). I’m sending out an update back to the Controller, and sending a CC event to the sequencer. H9 is the “on” value for the button Controller LED colour and H0 is the “off” value for the button Controller LED colour.

So for the counter for a loop I need to set an initial value, and then while in the loop I need to increment it, and test to see if I stay in the loop or break out. ThIs is where I get confused in MTPro because I think I’m not getting the parallel vs linear processing difference, or I’m a bigger idiot than I previously assumed. heh No matter where the counter increment is in the Translator, it will get incremented, right?

I’m coming in with a value vv that indicates the starting Row (offset) for the incoming Note Event which indexes the toggle bucket (vv=bit offset for the bitwise toggle thingie). So I want to initially set the counter to be the same as vv, and then cycle through the 4 offset values (0, 1, 2, 3)

(where vv=existing Row Offset variable of values 0,1,2,3; note offset=variable from 0-15 indicating which specific button; toggle value=extracted bitwise value of 0 or 1 based on if it is on or off); NOTE: I need to update all 4 buttons because the column works as one ‘unit’ – not all buttons are independent. That is, if button in Row 0 is pressed while Row 3 is playing, then Row 3 turns off. Also, if Row 3 is playing, and Row 3 is pressed again, it turns off

Sorry, I’m a pseudocode whore…

{counter}=vv
{counter}={counter}+1
if {counter}>3 then {counter}=0
if {counter}=vv then Exit/Execute

Outgoing:
97 {60+note offset} {(toggle value*difference between on/off values)+off value}
B0 {40+note offset} {126-(toggle value*126)}

This is just a tiny bit of the whole project and all 4 columns do not operate the same way. It’s really beyond my understanding, but I need to make this thing do those things because: reasons. heh

in my example, will that basically cycle through all 4 values? I’m lost at when I can define the initial value of the counter and keep that outside of the loop.

So, for iterative output I’d need to use a global variable, yes?
I’m confused on if/when/where you start the loop and where to test it so that it doesn’t keep restarting (infinite loop).

Or, I’m thinking if I have to Global the counter, as long as it’s in range (0-3) I can start the processing anywhere and just bop out when it does all 4.

My ‘brain map’ of how Do/While works and how MTPro approaches things is not reconciling.

OK, at the risk of making your head explode, I’m attaching an example of controlling 128 LED’s on and APC MINI (2 layers of 64) using Bitmapping.

I have 2 presets that are very similar, Bank 1 and Bank 2.  I have 4 global variables controlling LED states (on or off).

The first translator in each preset does figures out which bit and which global variable to toggle and toggles it. When done it sends a timer message to refresh LEDs which iterates through the LED’s (64 times with one global variable putting them into their respective state)

If you want to see it work more slowly, set the repeat delay of the timer to a higher value (if you have an APC 20)

This is from about 1 1/2 years ago so I had to look at it closely too.

I think this is somewhat what you are trying to do, right?

 

Hopefully you can learn by example.

 

In general if you need iterations, you use a global variable and a timer.

Within the timer, you can use local variables but make sure you update the iteration timer when you are done.

 

 

 

 

 

Okay, there’s a thing I never thought of doing because I never paid enough attention to the Timer options. That makes much more sense and thank you!

I prefer trying to figure out what other people have done, at least by knowing the concepts and then gleaning the logic and syntax from the example.

This is extremely helpful and I don’t know why I didn’t notice the timer thing before (yes, I’d looked at this script at least a week ago) heh heh