Developer’s Notes: Programming for the Motor Mix

PLEASE NOTE: This article has been archived. It first appeared on ProRec.com in November 1999, contributed by then Senior Editor Gary Simmons. We will not be making any updates to the article. Please visit the home page for our latest content. Thank you!

This supplemental describes how to program for the Motor Mix. I figured I’d give the hackers out there a head start on writing code to support the Motor Mix. I really like the unit and figure it can’t hurt to get more people writing code for it. Maybe someone will write a user configurable mapping utility to convert Motor Mix actions into whatever MIDI data a music application might find useful (hint, hint).

Reference First of all, you’ve got to be able to read and write MIDI data. I used Paul Messick’s “Maximum MIDI Toolkit” book (and CD) to build a C++ class to interface to the Motor Mix. I’d never written a bit of MIDI code in my life prior this, and it was pretty easy. Some of the best money I’ve ever spent on a book (ISBN 1-884777-44-9).

Daisy Chains You can connect multiple Motor Mixes together. The first one in the chain transmits on MIDI channel 1, the second one on channel 2, etc. You use the channel info in the incoming MIDI data to figure out which Motor Mix the user is twiddling. I don’t know how many people will buy more than one, but you can chain up to 16 of them together.

How it Works The Motor Mix sends Control Change (CC) messages. All your program has to do to respond to the Motor Mix is to deal with the barrage of CC messages you get. The manual comes with a MIDI implementation chart that explains what happens when every control is twiddled. Here are the Cliff Notes for Motor Mix developers. Note that all values are in hex.

When you press a button or move a fader, the Motor Mix sends out a “control group” message (BN-0F-xx), where N is the MIDI channel (zero-based), the “0F” indicates that it’s a “control group” message, and “xx” is the “group”. Channel strips 1 thru 8 are groups 0 thru 7. The Left, Right, View and Effect banks are control groups 8 thru 11. You get a control group message for every user action (button down, button up, etc.).

Buttons If the user twiddles a button, you’ll get a “press” message followed by a “release” message (BN-2F-yy). The “2F” indicates a button event and the “yy” indicates which button in the control group. The buttons are numbered from zero thru N within a group. The button id (the “yy” part) is offset by 0x40 for the “press” event. For example, the Mute button down message is BN-2F-02 and the Mute button release message is BN-2F-42. For my application, I basically ignore button releases and trigger all actions on button presses. How you implement the Shift key is up to you (i.e. make the user hold it down or use it like a toggle). I prefer using it like a toggle since it only requires one hand to operate.

Faders The faders have a range from 0-511. Obviously, the Motor Mix can’t send position info using a single byte. Fader position is transmitted using two consecutive messages. You get the MSB in a message like BN-(00 thru 07)-zz, where the (00 thru 07) is the control group (i.e. which fader) and the “zz” is the seven most significant bits of the position (0MMMMMMM). If you only need volume ranges from 0 – 127, then this is all the info you need.

Two more position bits are sent with the LSB message that follows the MSB message. The message looks like BN-(20 thru 27)-zz. Note the 0x20 offset on the control group part of the message. That’s your key it’s the LSB message, not the MSB message. The zz only uses two of the bits (0LL00000). You’ll have to do some bit-wise operations to tack the MSB to the LSB to get the fader position.

Knobs The knobs on the channel strip can spin continuously in either direction. They don’t “stop” like typical knobs on a console. As such, you really have no idea what “position” any given knob is in. It’s simply a way to turn stuff up or down from its current setting. When you turn a knob, you get a “knob” message such as BN-(40 thru 47)-xx. The range 40 thru 47 tells you it’s a knob twist. Subtract 0x40 to figure out which channel strip the knob is in. The “xx” (0DRRRRRR) consists of a direction bit (the “D”) and six rotation change bits (the “RRRRRR”). When the direction bit is set, it’s being turned clockwise. I found I needed to write a smoothing algorithm for the knob messages to make LUI Plus “feel” better.

Encoder Knob The Encoder knob is a continuous knob, like the ones on the channel strips, but you can feel it “click” thru its positions. The Encoder knob works just like the other knobs except the control id is 0x48 (not 0x40 thru 0x47). The Encoder knob can also be a switch (pushed down). This sends a BN-49-xx where “xx” is 0 for a release and 1 for a press.

That’s it. Now you’re all experts on dealing with input from the Motor Mix. Of course you’ll want to control the LEDs in the buttons and write stuff to the display so that Motor Mix reflects the state of your program. And you have to be able to move and position the faders when the user tweaks them via software.

LCD Screen Writing text to the LCD is matter of cobbling up a SysEx string. There’s a header (F0-00-01-0F-11-00) followed by the MIDI channel of the Motor Mix the message is destined for, followed by a 0x10 (indicates you’re writing text), followed by the position of the text (0x00 thru 0x4F), the text and finally the requisite 0xF7 to indicate end of SysEx. To make things more efficient, you want to write as little to the screen as possible and do the write in one command, not several (so you don’t keep resending the SysEx header stuff).

Controlling the LEDs Controlling the LEDs in the buttons is easy. You send a control group message (BN-0C-xx), where xx is the control group. Then send an LED command (BN-2C-yy) where yy is the LED you want to set. LEDs are numbered starting with zero within each control group. With no offset, the LED is turned off. Add 0x40 to the id to turn it On. Add 0x50 to make it blink.

Positioning Faders Setting a fader position is pretty simple too. It’s just the reverse of getting the info. You have to send out a pair of messages with the MSB and LSB in them. They are formatted just like the incoming messages.

Graphical Mode The Motor Mix LCD also has a “graphical” mode that lets do some very basic “graphics” (bar graphs mostly) on the LCD display. It’s basically the same idea as writing text to the display. You cobble up a SysEx string and let it rip. You could use these for things like level meters, gain reduction, pan position, and the Q (width) of an EQ. See the Motor Mix docs for more info on the different modes. I prefer seeing numbers to a coarse graphic, so I haven’t found the graphical modes too interesting. Your Mileage May Vary.

OK, Now What? So what does all this mean to you? The user does something to the Motor Mix. You have to figure out which control got twiddled. Based on logic in your app, you may or may not do something with that control. If you need to change the display or light an LED on the Motor Mix, you have to send out MIDI data to make that happen.

YOU – the developer – control every aspect of the Motor Mix. It does nothing on its own. That gives you all the flexibility you could ever want to use or abuse the Motor Mix any way you see fit. Remember, the labels on the buttons are just suggestions. You can map those buttons to anything your program can do. Of course it helps the user if the button label has *something* to do with the way you’ve used it.

Now go forth and write some code!