Bitwise - How Much Do I gain?

Okay, I'm in a quandary. I love MTPro because I can do SO MUCH. I hate MTPro because I spend more time coding than I do making music.

Working on a script to make a button controller do other things than it was designed to do. Have a script that kind of works. Can make it really elegant if I can figure out that bitwise mapping thing for holding multiple values and offsetting, etc. But also, that makes it tougher to troubleshoot if I want to change something later (because I'm old and an idiot).

What would I gain from a more 'elegant' script as opposed to some brute force barrage of if/then statements, which would ultimately be MUCH easier to debug when I come back to the script when I start making music again...which I haven't been doing...because I'm busy developing scripts (or rather, confused as heck trying to develop scripts)? :)

Do the number of lines of code slow down the processing in any perceivable way? Turning on/off Presets? Do I need to keep my code small to make it go faster?

Note: MTPro on BomeBox translating Note On/Off to CC toggles for controller a Squarp Pyramid. Not a straightforward 1 to 1 translation, tho - some different kind of grouping/relationships that make it a little more wonky.

Yes, I’m with you. The scripting is almost required for more complex stuff but the scripting language needs some work. The best I’ve been able to do when doing complex stuff is to comment EVERYTHING so that later you can remember what you did. Also, the more you can modularize functionality, the easier. For instance I don’t try to update LED’s on individual translator bases. I usually have a translator that periodically triggers a “Refresh LED” timer which is usually separate from anything I do for variable or bit manipulation.

I also create a library of “snippets” of code for doing complex things and then copy and past them in place when I need them. I just don’t like reinventing the wheel.

Hopefully sometime soon, we we will see something with a better embedded language. In the meantime, I just keep my tools handy. When I weigh the pro’s and con’s. I’ve yet to see something as powerful for MIDI processing a MT Pro but it comes with the price of complexity.

For those of you that don’t like to code, I’m available to help (free for tips on this board and fee for more complex stuff as an independent consultant/programmer time permitting so I can do music too).

I’m not sure if there was a question in there are not or you were just commenting and venting some of your concerns. If I missed the point and you have more of a direct question I can help with, I’m available.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

Well, the question was more along the lines of choice:

  • Work really really hard focusing all the time on getting this script to be as elegant, succinct, and sexy as possible.
  • Or just toss a nasty series of if/then statements in there as grunt work, but gets it done.

The former approach will require me to ask a bunch of stupid questions and continue my confusion, in addition to being more difficult to troubleshoot later. It’s at once both exciting and terrifying and there’s a bit of a rant in there because I can’t make these things work properly. The latter approach will get me a working script, but it will be spaghetti. Then again, if I use Global Variables for incoming Note Events and Outgoing Destination CCs, I can change things on the fly if I swap out my controller or decide to change things on the receiving gear.

Keep in mind that I don’t consult, I dont’ code for others, and a toolbox would be great if I spent time pgmg this more often than once or twice a year. But I don’t. I set up some scripts and just forget about it. But everytime I want to do something different, I have to re-learn how to do it (mostly because I’m old and the years have been abnormally harsh on my cognitive abilities).

So…if it’s going to be 10 to 20 times more code to do spaghetti, does that noticeably affect the processing or negatively impact latency when running an MTPro script on a BomeBox?

Well, I haven’t noticed anything major in the way of latency. There is some optimization in the say MT (and the Bome Version) processes incoming triggers so having more translators and less rules (if possible) would probably be more efficient. Also, I’m careful about how many translators and how often global variables are updated. Best to just have 1 translator or 2 to update a given global variable and as many as you want to read them. I try to pull my global variable into local space to work with them in a given translator. That way if the variable changes half way through your rules, you just run with what the beginning value was.

Once in a while I trip over timing with multiple translators updating a given global variable.

PS. I have to re-learn things all the time. Who knows, I might even be older than you;-)

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

“There is some optimization in the say MT (and the Bome Version) processes incoming triggers so having more translators and less rules (if possible) would probably be more efficient.”


This is different than the old Tips For Better Translating from the old forum. 🙂

“Favor rules over translators because it helps keep project size minimal…”

Although I think that is more about debugging, etc. 🙂

I think I’m pretty good with tracking Global Variables. I make all my variables have a meaning to the project, like “H” denotes drum stuff and I have 4 ‘levels’ that I’m tracking so they are HA HB HC HD, etc. Buckets for tracking toggles are H1, H2, H3, H4. This arrangement is repeated for other columns.

Big reasons for using Globals for me is using the same values in different Translators. I’m trying to use variables for incoming Note data and outgoing CC data so that I can change these values Globally if my rig changes (such as, say, a different button controller). Globals are only updated/calculated in one routine, but the values are referenced in several and it makes more sense to me to have separate Output routines (Zero Timers) to Output to separate Ports.

What I’m gleaning from these threads is:
– there isn’t really a preferred optimisation
– gobbley gook/spaghetti code is a problem mostly because it’s harder to debug
– be careful about globals but don’t ‘freak out’

Okay, I’m needing a Toolboxy approach on using that bitwise mapping thing to store 4 ‘toggle buckets’. I’ve spent the last few days researching posts here on the subject but I’m missing some significant concepts (I’m a systems/big picture person and I get lost on details & syntax). I never figured out how to do a single Toggle variable, but I hacked some of the examples here and it works. I need to refine the code tho, because I have 16 Toggles (so far) and might have up to 32 if/when I figure out what the rest of these buttons might do.

What resources would you suggest I visit (or Google search terms to find the most salient info) to figure out what the heck I’d be doing?

Need to create a Global Variable that will ‘store’ 4 toggle states. (G0, let’s say)
Need to be able to ‘query’ for a specific position, based on an existing variable. (Basically the offset. Value is 0,1,2,or 3)
Need to be able to Toggle (action) on one bit, or all bits.

I think I’m getting close to figuring it out, but I don’t quite know how to test what’s in my head yet.
Suggestions on further resources?

Hi, yes I normally prioritize on rules over translators unless:

  1. I get into performance issues (not very often)
  2. To help users that have problems with rules (very scary for some non-programmer types)
  3. Sometimes easier to document looking through list of translators than digging through rules.
  4. If I want to just do something “quick and dirty”

As far as bit mapping. Here is a reference that you might want to keep around that I found quite helpful. I keep it on Google Keep for a quick way to find it no matter what computer I’m on. It doesn’t go into bitmapping multiple bits because to me, I just use masking to extract into a global variable and then insert back in when I’m done with the manipulation.



Toggling a bit

Bit 0-31

pp=1<<xx – Where xx is bit number



Setting a bit

pp=1<<xx – xx is bit number to set


Clearing a bit

pp=1<<xx – xx is bit number to clear

Testing a bit

pp=ga>>xx — xx is bit number to test

pp will be the state of the bit – either 1 or 0

Iterating through 32 bits and output their state

Iteration timer – xx iterations -use gb=32 for interation number (note number)
start with high note and iterate down to 0

if gb<0 then exit rules, skip outgoing action

if qq==1 then rr=127
iif qq==0 then rr=0

Output 90 pp qq

On above if you want to iterate up from gb=0

if gb>31 then exit rules, skip outgoing action

…rest is same as above

XOR – If both are same, it is 0 otherwise 1
0^0= 0
0^1 = 1
1^0 = 1
1^1 = 0

AND – both bits need to be 1 for 1 output otherwise 0
0&0 = 0
1&0 = 0
0&1 = 0
1&1 = 1

OR – Either bits 1 to output 1

0|0 = 0
0|1 = 1
1|0 = 1
1|1 = 1

To make all 32 bits 1


Negative Numbers

Note that highest bit of a 32 bit signed integer is the “sign” bit.
When this bit is set, the value represents a negative number and the other bits are not represented by values of 1,2,4,8 etc.

To determine the negative value.

1 – Discard the sign bit (and make a mental note this is a negative number).
2 – Take the rest of the bits and invert them.
3 – Add 1 to the result

So for a value of FFFF FFFF
the sign bit is discarded and you have
Inverting the above gives you
0000 0000

Adding 1 give you
0000 0001

So the value of FFFF FFFF is really -1.

This is really only important in debugging since MT Pro will not show the hex or binary value. It will only show the decimal value. To make it easer, download a binary calculator. Make sure it is set for 32 bit precision. Enter the value in decimal and see the result in hex or binary.


Okay, thanks for reposting this.
I have it bookmarked on a previous post.
It never made complete sense before (even yesterday) but for some reason it looks completely different and understandable now. Whut?


I’m annoyed by MTPro not showing hex and moreso: converting my lovely hex numbers into decimal. It’s so much easier to work in hex!

Okay, I’m going to work on getting some small case test scenarios to work on the 4 bit toggle thingies stuff. LOL
Thank you for the info!

Yeah, I usually keep a hex calculator/converter handy. I also have started putting the hex value in comments just above the line that I do the calculation so that when MT Pro converts it to decimal (automatically), I can look at the line above to see the original hex value I entered. Makes reading my code easier without having to pull up my hex calculator.

I forgot that I posted the bitmapping reference before.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

One language question:
Toggling a bit = if it’s 1, make it 0; if it’s 0, make it 1
Setting a bit = regardless of the bit’s incoming state, make it a “1”?
Clearing a bit = regardless of the bit’s incoming state, make it a “0”?
Testing a bit = query/pull the bit’s state (0 or 1)
I mostly want to make sure my understanding of ‘setting’ and ‘clearing’ is correct, because english is difficult and my aforementioned “duh”.
And using GA per your example, making all bits value 0 would be ga=0?

Right on all counts.

Whew. Thanks!
That actually resolves my initial question since it means i can cut down on the number of Translators *and* Rules *and* Variables.
Thanks again, Steve!