metastatik
2013-01-28 15:47:57
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 getting to know as much as possible about the controller you’re using with MT. As they say, “knowledge is power” and that’s very, very true when working with MT. The more you know, the more you’ll be able to accomplish.
The Basics
At the very least, you should be familiar with the basic types of MIDI message (such as Notes, CCs and Pitch Bend) your controller sends and receives. The way in which you’ll figure this out depends on the controller.
If the controller utilizes a software editor or has onboard editing capabilities, this will allow you to easily see what type of MIDI messages it can send and, in some cases, even what MIDI messages it can receive. If not, look for downloadable/online references of the controller’s MIDI implementation. To give you some examples, here you’ll find a Programmer’s Guide for the Novation Launchpad and here you’ll find info on the Livid Instruments Ohm64. If neither of these solutions is an option, you can employ snooping (aka sniffing).
Snooping is the process of using a MIDI monitor application of some sort to look at the MIDI messages coming from a controller or other MIDI source. You can actually do this in MT itself by creating a translator, going to the Incoming tab, checking the Capture option and pressing/moving controls. Personally though, I prefer to use a dedicated application for this. On Windows, try MIDI-Ox. On OS X, try MIDI Monitor.
As an aside, most controllers with controls capable of receiving MIDI input (to light LEDs and such) will respond to the same messages they send.
Notes About Notes
MIDI messages are mostly standardized, but there are a couple of things about MIDI notes that aren’t and these can cause confusion.
The first is that octave names, such as the ‘1’ in C1 or the ‘4’ in D#4, aren’t standardized. The MIDI standard merely stipulates that note number 60 is middle C, it does not stipulate the name of its octave. For that reason, different manufacturers and software developers use different names for it and this causes disparity. I’d suggest forgetting about note/octave names as much as possible and instead concerning yourself with note numbers, which are the same everywhere. For example, note number 60 is always middle C, note number 0 is the lowest possible note and note number 127 is the highest possible note.
The second is that there are two different types of note off messages. First, in case you aren’t aware, a note message is typically composed of a note on message (sent when you press a key/pad/button) and a note off message (sent when you release a key/pad/button). Note on messages are all the same. They all look something like this: 90 0C 7F. The ‘9’ indicates that it’s a note on, the ‘0’ indicates the channel, the ‘0C’ indicates the note number and the ‘7F’ indicates the velocity.
Note off messages, however, come in two varieties. There is an actual note off message, which looks like this: 80 0C 00. This is similar to the structure of a note on except that the ‘8’ indicates that this is a note off. Then there is a note on message with a velocity of 0, which looks like this: 90 0C 00. This is identical to a note on, but with a velocity of 0. This is an important point to understand as each type of note off requires different handling.
Let’s look at an example. Let’s say you have a button that sends a note message, is velocity-sensitive (so you’ll need to use a variable in place of the velocity) and you want to set it up to send a CC message when it’s pressed.
If the controller uses actual note off messages, you’re golden. Otherwise, this will actually send the CC message on press and release; once for the velocity sent on press and once for the 0 velocity sent on release. To fix this, you simply need to filter out the velocity of 0. As it turns out, this will make this translator work with controllers that send either type of note off message.
Windows-specific Issues
There are a couple of things to be aware of when using MIDI Controllers with Windows. The first is that when using a controller with a dedicated driver (that was either provided with the controller or available via download), you should always connect the controller to the same USB port on your machine. Otherwise, the driver will get installed for each port you connect it to and this can cause problems.
The second is that controllers use one of two types of driver. The first is a single-client driver, which can only be used by one application at a time. If your controller uses a class-compliant driver, it’s single-client. If your controller has a dedicated driver, it’s most likely multi-client, which can be used in multiple applications simultaneously. As an aside, MT’s virtual ports are single-client.
Digging Deeper
Beyond the basic types of MIDI messages a controller’s controls can send and receive, many controllers have additional messages that they can either send or receive, which can be used to your advantage. For example, if a controller has a software editor, the editor is most likely communicating with the controller via SysEx. This SysEx can also be used to communicate with the controller with MT. There are several ways to find these additional messages depending on the controller.
The first place to look is in downloadable/online references of the controller’s MIDI implementation if available. For example, if you take a look at the Launchpad’s Programmer’s Guide, you’ll find that it can receive a message to turn all LEDs off and can receive a message to change the layout of its matrix among other things. As another example, many of Korg’s controllers send out SysEx messages when switching between scenes (and can also receive similar messages so that scenes can be changed remotely). There are MIDI implementation charts available for most of these controllers which cover these messages.
If no MIDI implementation info is available for your controller or you find the provided info too confusing, you can also use snooping to find additional messages used by the controller providing that the controller has an associated editor. For example, there is no MIDI implementation info available for the Akai MPD32, but it makes heavy use of SysEx and even includes a special mode that can be enabled where all of its buttons and controls (beyond those that are typically useable) send SysEx messages. The editor provided for the controller uses this SysEx and you can snoop on this.
To do this sort of snooping, you’ll need a MIDI monitor as discussed in the first section of this thread. You’ll basically just make changes in the editor and look at the MIDI monitor while doing so to see what the editor sends and the controller responds with. It’s also handy to monitor what the editor sends when it is initially launched.
On OS X, it’s dead easy because, AFAIK, all drivers on OS X are multi-client so MIDI Monitor can monitor data sent to/from the controller at the same time the controller is being used by the editor.
On Windows, it’s again dead easy if you have a controller with a multi-client driver. It’s a bit more complicated if you’re using a controller with a single-client driver such as an Akai MPD32. For this, you’ll need a set of virtual cables (MIDI Yoke is a good choice) in addition to a MIDI monitor with routing capabilities (such as MIDI-Ox).
You’ll first use MIDI-Ox to connect the controller’s primary input to a virtual output. Then you’ll connect the controller’s primary output to a virtual input. Personally, I like to use 2 instances of MIDI-Ox for this; one for output, one for input. In any case, you’ll make these connections in Port Routings, which is available from the View menu. Next, you’ll configure the controller’s editor to use the virtual ports you set up in MIDI-Ox.
Write It Down
Once you’ve discovered details about your controller, it’s a good idea to make charts for yourself that describe it in ways that make sense to you. In some cases (such as with the Launchpad), the manufacturers have already done this for you in a very clear way. In other cases though, manufacturer documentation is either non-existent or confusing, so you’ll have to do it yourself.
Since we work with both decimal (in Rules) and hexdecimal (in Incoming and Outgoing messages) in MT, it’s a good idea to notate MIDI messages in both decimal and hexadecimal. Take a look at the Launchpad’s Programmer’s Guide for an example of this.
In this post, we’ll talk about getting to know as much as possible about the controller you’re using with MT. As they say, “knowledge is power” and that’s very, very true when working with MT. The more you know, the more you’ll be able to accomplish.
The Basics
At the very least, you should be familiar with the basic types of MIDI message (such as Notes, CCs and Pitch Bend) your controller sends and receives. The way in which you’ll figure this out depends on the controller.
If the controller utilizes a software editor or has onboard editing capabilities, this will allow you to easily see what type of MIDI messages it can send and, in some cases, even what MIDI messages it can receive. If not, look for downloadable/online references of the controller’s MIDI implementation. To give you some examples, here you’ll find a Programmer’s Guide for the Novation Launchpad and here you’ll find info on the Livid Instruments Ohm64. If neither of these solutions is an option, you can employ snooping (aka sniffing).
Snooping is the process of using a MIDI monitor application of some sort to look at the MIDI messages coming from a controller or other MIDI source. You can actually do this in MT itself by creating a translator, going to the Incoming tab, checking the Capture option and pressing/moving controls. Personally though, I prefer to use a dedicated application for this. On Windows, try MIDI-Ox. On OS X, try MIDI Monitor.
As an aside, most controllers with controls capable of receiving MIDI input (to light LEDs and such) will respond to the same messages they send.
Notes About Notes
MIDI messages are mostly standardized, but there are a couple of things about MIDI notes that aren’t and these can cause confusion.
The first is that octave names, such as the ‘1’ in C1 or the ‘4’ in D#4, aren’t standardized. The MIDI standard merely stipulates that note number 60 is middle C, it does not stipulate the name of its octave. For that reason, different manufacturers and software developers use different names for it and this causes disparity. I’d suggest forgetting about note/octave names as much as possible and instead concerning yourself with note numbers, which are the same everywhere. For example, note number 60 is always middle C, note number 0 is the lowest possible note and note number 127 is the highest possible note.
The second is that there are two different types of note off messages. First, in case you aren’t aware, a note message is typically composed of a note on message (sent when you press a key/pad/button) and a note off message (sent when you release a key/pad/button). Note on messages are all the same. They all look something like this: 90 0C 7F. The ‘9’ indicates that it’s a note on, the ‘0’ indicates the channel, the ‘0C’ indicates the note number and the ‘7F’ indicates the velocity.
Note off messages, however, come in two varieties. There is an actual note off message, which looks like this: 80 0C 00. This is similar to the structure of a note on except that the ‘8’ indicates that this is a note off. Then there is a note on message with a velocity of 0, which looks like this: 90 0C 00. This is identical to a note on, but with a velocity of 0. This is an important point to understand as each type of note off requires different handling.
Let’s look at an example. Let’s say you have a button that sends a note message, is velocity-sensitive (so you’ll need to use a variable in place of the velocity) and you want to set it up to send a CC message when it’s pressed.
Code: Select all
Incoming: 90 0C vv
Outgoing: B0 00 vvCode: Select all
Incoming: 90 0C vv
Rules:
if vv == 0 then exit rules, skip Outgoing Action
Outgoing: B0 00 vvThere are a couple of things to be aware of when using MIDI Controllers with Windows. The first is that when using a controller with a dedicated driver (that was either provided with the controller or available via download), you should always connect the controller to the same USB port on your machine. Otherwise, the driver will get installed for each port you connect it to and this can cause problems.
The second is that controllers use one of two types of driver. The first is a single-client driver, which can only be used by one application at a time. If your controller uses a class-compliant driver, it’s single-client. If your controller has a dedicated driver, it’s most likely multi-client, which can be used in multiple applications simultaneously. As an aside, MT’s virtual ports are single-client.
Digging Deeper
Beyond the basic types of MIDI messages a controller’s controls can send and receive, many controllers have additional messages that they can either send or receive, which can be used to your advantage. For example, if a controller has a software editor, the editor is most likely communicating with the controller via SysEx. This SysEx can also be used to communicate with the controller with MT. There are several ways to find these additional messages depending on the controller.
The first place to look is in downloadable/online references of the controller’s MIDI implementation if available. For example, if you take a look at the Launchpad’s Programmer’s Guide, you’ll find that it can receive a message to turn all LEDs off and can receive a message to change the layout of its matrix among other things. As another example, many of Korg’s controllers send out SysEx messages when switching between scenes (and can also receive similar messages so that scenes can be changed remotely). There are MIDI implementation charts available for most of these controllers which cover these messages.
If no MIDI implementation info is available for your controller or you find the provided info too confusing, you can also use snooping to find additional messages used by the controller providing that the controller has an associated editor. For example, there is no MIDI implementation info available for the Akai MPD32, but it makes heavy use of SysEx and even includes a special mode that can be enabled where all of its buttons and controls (beyond those that are typically useable) send SysEx messages. The editor provided for the controller uses this SysEx and you can snoop on this.
To do this sort of snooping, you’ll need a MIDI monitor as discussed in the first section of this thread. You’ll basically just make changes in the editor and look at the MIDI monitor while doing so to see what the editor sends and the controller responds with. It’s also handy to monitor what the editor sends when it is initially launched.
On OS X, it’s dead easy because, AFAIK, all drivers on OS X are multi-client so MIDI Monitor can monitor data sent to/from the controller at the same time the controller is being used by the editor.
On Windows, it’s again dead easy if you have a controller with a multi-client driver. It’s a bit more complicated if you’re using a controller with a single-client driver such as an Akai MPD32. For this, you’ll need a set of virtual cables (MIDI Yoke is a good choice) in addition to a MIDI monitor with routing capabilities (such as MIDI-Ox).
You’ll first use MIDI-Ox to connect the controller’s primary input to a virtual output. Then you’ll connect the controller’s primary output to a virtual input. Personally, I like to use 2 instances of MIDI-Ox for this; one for output, one for input. In any case, you’ll make these connections in Port Routings, which is available from the View menu. Next, you’ll configure the controller’s editor to use the virtual ports you set up in MIDI-Ox.
Write It Down
Once you’ve discovered details about your controller, it’s a good idea to make charts for yourself that describe it in ways that make sense to you. In some cases (such as with the Launchpad), the manufacturers have already done this for you in a very clear way. In other cases though, manufacturer documentation is either non-existent or confusing, so you’ll have to do it yourself.
Since we work with both decimal (in Rules) and hexdecimal (in Incoming and Outgoing messages) in MT, it’s a good idea to notate MIDI messages in both decimal and hexadecimal. Take a look at the Launchpad’s Programmer’s Guide for an example of this.