**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 Method to the Madness, I mentioned favoring rules over translators, gave an example relating to the Launchpad and promised to discuss that further in a future post. Well, here it is! Please note, however, that you do not need a Launchpad to follow along here. What we’ll be discussing is more about MIDI messages and, more specifically, how to elegantly deal with groups of them. In this case, we’ll be discussing a button matrix, but similar ideology can be applied to any sort of control group.

**The Plan**

In the example given in Method to the Madness, I mentioned setting up a page of 8 button faders, so that’s precisely what we’ll be doing here. Before implementing functionality in MT, it helps to have as clear a picture as possible of what you’re going for. Here, we’ve got a vague image so far, so let’s clarify it some more before going further.

This image shows the Launchpad’s default MIDI messages, which is our starting point.

This image shows the superimposed button fader implementation, which is our ending point.

**First Attempt**

As a first attempt, we might think to just use 64 separate translators. Method to the Madness discusses why this is a bad idea, but let’s take a look at it anyways.

We’d create a translator for each button. Let’s start with the first (leftmost) column. The translator for the uppermost button would look like this:

Code: Select all

```
Incoming: 90 00 7F
Outgoing: B0 00 7F
```

Code: Select all

```
Incoming: 90 10 7F
Outgoing: B0 00 6C
```

**Taking A Step Back**

As discussed in Method to the Madness, we’d be much better off using 8 or, better yet, 1 translator to do this. To accomplish this, we need to find the logic in both our starting and ending points.

In the ending point, it’s easy to see that each column of buttons sends the same CC. Likewise, each row of buttons sends the same value. This is very simple logic so, really, we should be able to do this with just 1 translator providing that we can find a way to deal with the matrix in terms of coordinates. Instead of being concerned about which note a button sent, we’d like to know which column and row it’s on.

To accomplish this, we have to go back to the starting point and try to find the logic in terms of the way the notes are laid out. If you start with the upper leftmost button and work your way down, what is occurring with the note numbers? Does the same hold true when moving down other columns? Likewise, if you start with the upper leftmost button and work your way across, what is occurring with the note numbers? Does the same hold true when moving across other rows? Try to figure this out on your own before reading on.

You should’ve found the row numbering increases by 16 as you move down and the column numbering increases by 1 as you move across. This is the logic we needed to find.

**Initial Skeleton**

Before we get to working on the rules, let’s create a simple skeleton translator that will handle what we’re looking to do here. Unlike the translators used in our First Attempt, we need a translator that can receive any note in the matrix and send out any of the CCs and values needed by our button faders.

We know that all notes in the matrix use channel 1 and that all the button faders also use channel 1. So here is what our skeleton would look like.

Code: Select all

```
Incoming: 90 pp 7F
Outgoing: B0 oo vv
```

**Deriving Coordinates**

As mentioned in Taking A Step Back, we’d like to deal with coordinates. So, before we look at actually implementing our button faders, we need to figure out how to derive coordinates based on the notes the matrix sends. For example, if we receive note #0, we want to derive row 0/column 0. If we receive note #52, we want to derive row 3/column 4.

What sorts of rules can we use to accomplish this? I’ll give you a big hint, the general form of the rules we need are covered in Golden Rules. Try to figure this out on your own before reading on.

First, let’s look at deriving the row. As we found in Taking A Step Back, row numbering increases by 16. So what we want to do here is figure out how many 16s are in the note numbers we receive. What sort of mathematical equation can you use to figure that out? Division, right? As mentioned in Golden Rules, it’s a good idea to try out rules on paper, so give it a try and make sure it works. We’ll try a couple of examples here.

Code: Select all

`0=0/16`

Code: Select all

`3=52/16`

Code: Select all

`rr=pp/16`

Code: Select all

```
0=0/16
0=0*16
```

Code: Select all

```
3=52/16
48=3*16
```

Code: Select all

```
rr=pp/16
ss=rr*16
```

Code: Select all

```
0=0/16
0=0*16
0=0-0
```

Code: Select all

```
3=52/16
48=3*16
4=52-48
```

Code: Select all

```
rr=pp/16
ss=rr*16
oo=pp-ss
```

**Filtering**

As mentioned in Initial Skeleton, we’ll need to apply some filtering to prevent the 8 buttons on the right side of the Launchpad from triggering our translator. Typically, you want to do your filtering in the first rule(s). However, in this case, it would be impractical as we’d need a bunch of rules to do that. Now that we’ve derived coordinates, we can simply filter out that entire column with just one rule.

Code: Select all

`if oo==8 then exit rules, skip Outgoing Action`

**Implementing The Faders**

Up until this point, everything we’ve discussed is the general way you’d deal with the Launchpad’s matrix regardless of what functionality you were implementing. Now, we’ll get into discussing implementing the functionality we’re after, which is our 8 button faders.

Part of the work is already done. The column value (oo) is equal to the CC# our button faders send, so we’ll simply pass that to the Outgoing message. The CC value is a bit trickier.

First of all, our row value (rr) increases as you move down while our button faders are supposed to increase as you move up. How do we fix this? With another one of the Golden Rules, The Inversion Rule.

Code: Select all

`vv=7-rr`

Code: Select all

```
vv=vv*18
if vv==126 then vv=127
```

**Putting It All Together**

Our finalized translator will look like this.

Code: Select all

```
Incoming: 90 pp 7F
Rules:
rr=pp/16
ss=rr*16
oo=pp-ss
if oo==8 then exit rules, skip Outgoing Action
vv=7-rr
vv=vv*18
if vv==126 then vv=127
Outgoing: B0 oo vv
```

Of course, the logic of the Launchpad’s layout that we used to derive coordinates is specific to it, but other controllers (such as the APC40) are logically laid out as well and can be expressed mathematically just as we did here. The take home point here is to take a look at what you’re starting with and what you want to end up with, try to figure out the logic at both ends and use rules to express it.