This forum is read-only. Please post new topics in our Q&A forum.

## Tips For Better Translating #2 – Golden Rules

metastatik
Power User
Posts: 61
Joined: Wed Sep 26, 2007 6:02 pm

### Tips For Better Translating #2 – Golden Rules

DISCLAIMER: Although I have used MT for many years, I have never read MT’s manual as there was no manual available when I started using it. So my approach and the tips that will follow mostly come from trial and error as well as some things I learned here on the forum (mostly from Florian’s posts). For that reason, I’d suggest using your own discretion in terms of which tips you take away from this post.

In this post, we’ll talk about common rules that can be used in a variety of situations. It’s a good idea to have a mental catalog of these sorts of rules as it helps when developing more complex rules, which are usually built up from a series of simpler rules.

Also, when developing more complex rules, I highly recommend working them out on paper first. This way, you can test things out before plugging the rules into MT. To do that, you simply have to know the structure of each type of rule MT allows. You also have to understand how rules are processed. There are really just two things to be aware of on this.

The first is that rules are processed from top to bottom. You can, of course, change that by using Gotos and Labels. But you should keep in mind the top to bottom ordering and understand that this results in sort of implicit rules. For example, it never makes sense to have “exit rules, execute Outgoing Action” as the last rule. This is implicit (it happens whether that rule is there or not).

The second is that we work purely with integers (whole numbers) in MT. This is primarily important to keep in mind when doing division. For example, if you divide 5 by 2 in MT, the result will be 2, not 2.5 or 3. If the result of a division would typically include a decimal point, everything after the decimal point just gets truncated off and no rounding occurs.

Following are what I consider to be my “golden rules” that I use regularly.

The Toggle Rule
Very simple, but useful rule that toggles between 0 and another value. Useful for turning a momentary control into a toggle or for setting up a momentary control as a shift control.

Examples:

Code: Select all

``ga=1-ga``

Code: Select all

``ga=127-ga``
This can also be used for toggling between any two values by applying an offset. For example, if you wanted to toggle between 24 and 63 (the difference between the two being 39):

Code: Select all

``````pp=39-ga
ga=pp+24``````
The Inversion Rule
This rule inverts a range of values and is very similar to the Toggle Rule.

For example, let’s say you have a knob that outputs values that range from 0 – 127 and you wanted to invert the range so that it would go from 127 – 0. The following will take the incoming value from the knob (pp) and invert the output (oo).

Code: Select all

``oo=127-pp``
If you had a range that did not start out at 0, you’d have to do some extra work similar to what we did with the Toggle Rule. For example, if you had a control that output values that ranged from 53 – 57 (pp), the following would invert it to 57 – 53 (oo).

Code: Select all

``````oo=57-pp
oo=oo+53``````
The Count Rule
This rule simply counts up or down. You can have it count infinitely or your can put restraints on the min/max values of the count. Useful for determining if any note is being played, for thinning out data and for selecting between different sets of rules to execute.

Examples:

Code: Select all

``ga=ga+1``

Code: Select all

``````ga=ga+1
if ga>10 then ga=0``````
The Compare and Store Rule
This will compare the incoming value against the last stored value and exit if they’re the same or, if they aren’t the same, it will store the incoming value. This is useful in situations where you only want Outgoing Actions (or additional rules) to occur when values change.

Example:

Code: Select all

``````if pp==ga then exit rules, skip Outgoing Action
ga=pp``````
The Scaling Rule
This is useful for scaling the range of a control.

For example, let’s say you have a knob that outputs values that range from 0 – 127 and you wanted to use this knob to control something with a range of 0 – 15. The following will scale the incoming value from the knob (pp) so that the output value (oo) will be within the range of 0 – 15. Notice that we’ve also used the Compare and Store Rule here. Reason being, the scaling here could allow each scaled value to be sent up to 8 times. Compare and Store prevents this. This is an example of how “golden rules” can be used to build more complex rules.

Code: Select all

``````oo=pp/8
if oo==ga then exit rules, skip Outgoing Action
ga=oo``````
So how you do figure out the value to divide by? You take the steps in your incoming range (128) and you divide it by the steps in your outgoing range (16). Remember that 0 is a step, so 0 – 127 is not 127 steps, it’s 128 steps! However, this won’t always work.

For example, let’s say you wanted your knob (range 0 – 127) to have an outgoing range of 0 – 6. So you’d divide 128 by 7 and you’d get 18.2857…etc. That’s a problem because MT only deals with integers (whole numbers) so you can’t divide by 18.2857 and dividing by 18 won’t yield the result we want.

How do we get around this? One solution is to boost everything up by a factor of 100 (though 1000 may be more appropriate in some cases) as shown below. First, multiply the result from above by 100 (1828). Now you can multiply the incoming value by 100, divide it by 1828 and the output will be scaled to 0 – 6.

Code: Select all

``````rr=pp*100
oo=rr/1828
if oo==ga then exit rules, skip Outgoing Action
ga=oo``````
The Modulo Rule
First of all, what the heck is a modulo? Google it. In short though, a modulo is a type of operator (like + or -) that is used to determine what is left over after dividing integers. For example, if you divide 5 by 2 in MT, the result is going to be 2 with a remainder left over (1 in this case). The modulo operator (usually written like 5 % 2) tells you what the remainder is.

This is useful in many cases where you’re dealing with a range of values (like multiple octaves of keys on a controller) that are based on a smaller range of values (each octave is the same 12 notes). For example, say you wanted a translator that could detect which note was played regardless of octave.

Code: Select all

``qq=pp%12``
The qq variable will hold the note (a value in the range of 0 – 11) where 0 is a C, 1 is a C#, etc.

[the following additions by Florian and sjcaldwell]

AND and OR conditions, ELSE clause
Often, you need to test 2 (or more) conditions, and only do something when all conditions are satisfied (AND), or when any one condition is satisfied (OR). Here are a few ideas, also for an ELSE clause:

Code: Select all

``````//  if pp==2 AND qq==3 then oo=7 else oo=4
oo=4
if pp!=2 then skip next 2 rules
if qq!= 3 then skip next rule
oo=7

// if pp==2 OR qq==3 then oo=7 else oo=4
oo=4
if pp==2 then oo=7
if qq==3 then oo=7
``````
Last edited by metastatik on Sun Mar 27, 2016 7:43 pm, edited 1 time in total.

DarrylB
User
Posts: 8
Joined: Sat Feb 20, 2016 10:58 am

### Re: Tips For Better Translating #2 – Golden Rules

Hi Metastatik,

Thanks for the tips - I'm looking to embark on using Bome MIDI to handle the motorized platter from a Numark NS7 in OtsAV. So I'm doing a little research into it's capabilities before I begin.

I think you've made a mistake in your modulo rule example you said "if you divide 5 by 2 in MT, the result is going to be 2 with a remainder left over (3 in this case)." 2 goes into 5 twice (2*2 = 4) with a remainder of 1. So I think it should say with a remainder of 1 in this case.

metastatik
Power User
Posts: 61
Joined: Wed Sep 26, 2007 6:02 pm

### Re: Tips For Better Translating #2 – Golden Rules

You're absolutely right! Thanks for pointing this out.