The Musical Instrument Digital Interface (MIDI) specification opened up a new world of flexibility in electronic instruments, especially in keyboards. MIDI allows a collection of musical devices to communicate with each other, and eliminates the need to drag along a large collection of bulky keyboards to gigs -– a player only has two hands; why bring more than two keyboards?

Well, that’s how MIDI is supposed to work. As in most things, there are differences between the concept and practice of MIDI, and things don’t always work out as expected. Different musical products have varying degrees of MIDI support, and some manufacturers have interpreted the specifications differently that others. Even if two MIDI devices claim to support a feature (ex: keyboard velocity), there may be problems linking the two devices together.

MIDI Solutions’ little "black boxes" have always provided easy answers to tricky MIDI problems, but the Event Processor™, and its big brother, the Event Processor Plus™ take this ability to a new level. With this new ability comes new complexity, and some users may find the programming capabilities of these boxes a little overwhelming at first. This guide attempts to remove some of the mystery of the Event Processor and Event Processor Plus, allowing users to program these boxes to their full capabilities.

NOTE:  In the remaining passages of the guide, we’ll refer to both the Event Processor and Event Processor Plus as simply the "Event Processor." In cases where the Event Processor Plus provides additional capabilities, we’ll refer to it as the "Plus."

WHAT CAN THE EVENT PROCESSOR DO?

• It can filter specific types of MIDI events to prevent other devices from seeing them;

• It can map (convert) one MIDI event into a different event;

• It can trigger a new event (or series of events) based on an incoming MIDI message;

• It can sequence through a series of events each time an incoming message is received;

• It can enable or disable some of its settings based on the events it sees;

• It can store data values and operating settings for later use.

Each of these features can be used in both simple and complex ways, as we will see in later sections.

HOW THE GUIDE IS ARRANGED

This programming guide contains a series of examples that show how the Event Processor can be used to solve real-world problems on MIDI equipment. Generally, the examples are practical ones based on real MIDI products, and some readers may find that their problems are directly solved by one or more of the examples.

Chapter 1 describes using the features of the Event Processor to solve simple, but often annoying, problems in MIDI gear. All owners of the Event Processor will want to read through this section, regardless of their level of MIDI knowledge.

Chapter 2 moves on to more complicated MIDI setups, and how the Event Processor can use several settings together to solve more complicated problems. Advanced users and MIDI “experts” will want to read through this section, too, as it opens up a new level of capabilities in the Event Processor. Users who are less skilled at the finer points of MIDI may want to browse this section to understand what the devices can do, and return at a later time to attempt complex programming, or arrange for programming help through MIDI Solutions or your dealer.

Chapter 3 will discuss problems and limitations caused by the MIDI data itself, or by the way the Event Processor handles the data. These are important points to keep in mind, especially when programming complex tasks in the Event Processor. The Event Processor may seem to be a “MIDI magician,” but it has to obey a set of rules, too.

BEFORE WE MOVE ON ...

In order to program the Event Processor, the user must have a general technical understanding of how MIDI works. A complete explanation of the MIDI protocol is beyond the scope of this guide. Users who are new to the world of MIDI are encouraged to read one or more of the available books on MIDI before attempting to program the Event Processor. Some of these books include:

• MIDI for Musicians by Craig Anderton; Music Sales Corporation, ISBN: 0825610508

• Basic MIDI by Paul White; Sanctuary Publishing, Ltd, ISBN: 1860742629

• MIDI for the Professional by Paul Lehrman, Tim Tully; Music Sales Corporation, ISBN: 0825613744

• MIDI for the Technophobe by Paul White; Sanctuary Press (UK), ISBN: 1860744443

• MIDI Power! by Robert Guérin; Muska & Lipman/Premier-Trade, ISBN: 1929685661

• The MIDI Manual, Second Edition by David Miles Huber; Focal Press, ISBN: 0240803302

PROGRAMMING DEFINITIONS AND BASIC CONCEPTS

The MIDI Solutions Event Processor Programming Tools use terminology designed around the needs of the MIDI protocol, and the Event Processor itself. Some of the most important ones to become familiar with are:

• Events –- a MIDI command being sent is considered a MIDI ‘event.’ Events include notes being played, knobs being turned, and clock information being sent, as well as many other items. Think of an event as being the sending of a single type of MIDI information that we want to act upon.

• Setting –- Each ‘Setting’ is a single task that the Event Processor can perform. In many cases, a Setting can also be thought of as a feature or function that we want the Event Processor to provide, like mapping a controller value or changing the MIDI channel of a message. Sometimes, though, it takes two or more Settings to produce the desired results. (This will become clearer as we continue in the guide.)

• Value X -– a temporary value used to represent a range of values that a data byte in a MIDI command might send. Many times, while we don’t know what the exact value of the data will be in a specific message, we want to pass the data on, either directly or after modifying the message. The term ‘Value’ allows us to keep track of the data and instruct the Event Processor to use the data in its Settings.

  Most MIDI commands are made up of two or more bytes; typically, either two or three bytes. The first byte is the ‘Command Byte,’ which tells what type of information is being sent (Note-On, Controller Change, etc.). The remaining bytes are the ‘data’ bytes – except in the case of System Exclusive (SysEx) data, which we’ll discuss briefly in the next section. In the Event Processor we’ll call the two typical data bytes ‘Value X’ and ‘Value Y’. Generally, Value X refers a range of values in the first of the two data bytes, or in the only data byte in the command.

  The actual information in Value X changes between MIDI commands. In a Note-On command, for example, Value X tells us which note is being played; in a Control Change command, it tells us which controller is being adjusted. Thus, we need to call them something to keep track of the information that they contain.

  [Please note: The concept of Values is a necessary part of the flexibility of the device, and something that users will either grasp immediately, or will just have to accept as part of the programming process. Like your mother told you, you shouldn’t be afraid to try new things!]

• Value Y –- another temporary value used to represent a range of values in the MIDI command. Generally, Value Y refers to the second of two data bytes. Like Value X, Value Y information varies between MIDI commands; in our Note-On example, Value Y is the velocity of the note being played; in the Control Change example, Value Y is the value (knob position, etc.) of the control.

MIDI DATA TYPES

The Event Processor can work on all of the various types of MIDI data. The basic data types include:

• Note On -– As expected, this is the command that tells a sound module to play a note. The first byte, called the ‘Command Byte,’ tells us that this is a note message, and the MIDI channel being used. The next two bytes tell the note number (0-127) and the velocity (0-127). Devices which do not send velocity are free to send any value in the third byte except zero. In the Event Processor, the note number is treated as Value X, and the velocity is treated as Value Y.

• Note Off -– The counterpart to Note On, this command is rarely used; instead, a Note On with velocity of zero is used to show keys being released. Devices which support Note Off send the note number (0-127) and ‘release velocity’ (0-127). In the Event Processor, the note number is Value X, and the release velocity is Value Y.

• Polyphonic Pressure –- This rarely-used feature of MIDI provides individual key pressure (Aftertouch) information for every key in a MIDI keyboards. Devices which support Polyphonic Pressure send the note number (0-127) and pressure amount (0-127). In the Event Processor, the note number is Value X, and the pressure amount is Value Y.

• Continuous Controller (CC) -– This command describes the movement of the knobs, switches, pedals, etc. that a MIDI device uses to make adjustments during performance. This is one of the most common MIDI commands that we will want to use in the Event Processor, and despite its name, often represents controls (like switches) that don’t provide a continuous range of settings; instead, they use 0 for off and 127 for on. Its two data bytes tell us the controller number (0-127) and the controller position (0-127). In the Event Processor, the controller number is Value X and the position is Value Y.

• Program Change -– This command calls up a stored program on the device. It has only one data byte which provides the program number (0-127). In the Event Processor, the program number is Value X.

• Channel Pressure or Aftertouch -– Most MIDI keyboards that support Aftertouch use this method, which sends one key pressure value for the entire keyboard. It also has only one data byte which provides the pressure amount (0-127). In the Event Processor, the pressure is Value X.

• Pitch Bend -– This message defines the position of the Pitch Bender, which is usually a wheel, ribbon, or lever that automatically returns to its middle position. The command is somewhat unusual in that it both allows for a greater range of values than 0-127, and positive (up) and negative (down) bends. It has two data bytes which are used together to provide the bend value. In the Event Processor, the first data byte is Value X and the second data byte is Value Y.

• System Real Time -– These messages include things like Clock, Start, Stop, System Reset, and Active Sensing. All of these messages have no MIDI channel, but are sent to all devices at once.

There are also some special data types that we need to address. Because these data types are more complicated, we’ll spend a little extra time discussing them:

SYSTEM EXCLUSIVE (SYSEX)

This data format was developed by the originators of the MIDI specification to allow manufacturers to send model-specific data that wasn’t planned for in the basic MIDI architecture. For the most part, these messages are used for less common MIDI tasks like transferring data to and from devices, or selecting special features that cannot be controlled through normal MIDI commands. SysEx commands have no associated MIDI channel; any device on the line is supposed to monitor for SysEx messages, and act on them as necessary. If the device doesn’t act on the message, it’s supposed to sit quietly until the message ends.

SysEx messages have a unique format, and are usually expressed in Hexadecimal (base 16), rather than Decimal (base 10): The first byte is always F0 (240), followed by several bytes to show the device’s manufacturer or brand, and usually, the model of the device itself. The last byte is called the ‘EOF’ byte, and is always F7 (247). The following is an example of a SysEx message:

In between the starting byte/ID and the EOF, all of the other bytes are undefined by MIDI, and can be whatever the manufacturer chooses, but each byte cannot have a value greater than 7Fh (127). SysEx messages can be very long, often thousands of bytes in length. SysEx isn’t really intended for device-to-device communications, as much as for device-to-programmer or device-to-manufacturer needs. SysEx is also intended for infrequent communications, because it talks to every device, on every channel.

REGISTERED PARAMETER NUMBER (RPN)

As the use of MIDI expanded, some manufacturers started to work around the limitations of MIDI by sending all their information, even simple messages like knob and switch changes, through SysEx. This defeats the purpose of MIDI, which is to provide a simple, universal communications standard for all musical devices to use. It also slows down general MIDI communications by forcing everyone to pay attention to the messages. Two new data standards, RPN and NRPN, were developed to enhance MIDI control abilities without resorting to SysEx. Both standards start by using Control Change (CC) messages to tell the MIDI ‘world” that they want to communicate outside the limits of standard MIDI.

RPN is the more structured of the two standards. If I were to decide that toasting bagels was a feature that MIDI instruments needed to address, and the MIDI Manufacturers Association agreed that my this was in the best interest of the general MIDI community (not likely!), they would ‘register’ one of the roughly 16,000 RPN locations as being used for – and only for – toasting bagels. Certain limits would also be imposed on the data being sent by this new RPN, so that everyone would understand the messages. Some RPN examples are Master Tuning and Pitch Bend Range. For obvious reasons, there have been few RPN controls established: most MIDI needs can be met by other controllers of MIDI, and most of the remaining items tend to be very specific to one or two devices.

In theory, at least, no one is supposed to use any of the unregistered RPN locations – ever.

RPN uses the data byte of two MIDI controller locations, CC#100 and CC#101, to call out a specific RPN. At that point, changes to the RPN use the Data Slider (CC#6). In shorthand, a typical RPN command might look like this:

      CC#100 = 40h (64)
      CC#101 = 22h (34)
      CC#6 = 127

This set of three CC messages would set the value of the RPN defined at 2022 in Hexadecimal -- 7-bit math is in use here, because the highest bit of a data byte cannot be a '1' -- as having a value of 127. Once an RPN is called out, additional messages can be sent by changing CC#6 only, since control of the Data Slider is now in the hands of the RPN. However, if someone else calls up a different RPN, the three-byte message must be sent again to reclaim the Data Slider.

To be safe and simple, it’s best to send the three-byte version of the RPN each time it’s used; however, this method triples the amount of data being sent with each RPN change. When programming the Event Processor to work with RPN controls, the user will have to consider tradeoffs between simplicity and data size. If the setup only uses one or RPN controls, it may be sufficient to only send the full three-command sequence at the beginning of use, or after the Event Processor detects a different RPN message header.

NON-REGISTERED PARAMETER NUMBER (NRPN)

NRPN is the ‘back door’ approach for those of us bagel toasters can’t convince the mainstream MIDI community to adopt our ways and decide to implement the function, anyway. Each manufacturer can use NRPN to define commands that are unique to a particular product, and my bagel toasting NRPN is actually free to conflict with your NRPN to put toothpaste on a toothbrush. Since there are roughly 16,000 NRPN locations, it’s possible to stay out of the way of others most of the time, but NRPN conflicts can and do happen. To prevent this problem, devices often send an initialization message, or a series of them, at power-up to establish their NRPN “turf.”

Like RPN, NRPN uses the data byte of two MIDI controller locations, CC#98 and CC#99, to call out a specific NRPN. At that point, changes to the NRPN use the Data Slider. A typical RPN command might look like this:

      CC#98 = 20h (32)
      CC#99 = 00h (0)
      CC#6 = 100

This set of three CC messages would set the value of the RPN defined at 1000 in Hexadecimal as having a value of 100. Once an NRPN is called out, additional messages can be sent by changing CC#6 only, but again, this is only true if no other NRPN message has been sent in between. Like RPN, there is a tradeoff between safety/simplicity and generating extra data that must be made.

Please also note that both RPN and NRPN controls use the Data Slider, so an RPN or NRPN controller must check for both kinds of messages before assuming that the Data Slider is still ‘owned’ by that RPN or NRPN.