CHAPTER 3 – LIMITATIONS AND PITFALLS


OK, by now you’ve probably figured out that there’s nothing MIDI that the Event Processor can’t deal with, right? Well, not quite. Did you ever get behind the wheel of a really powerful car or motorbike –- one that had more horsepower than you ever dreamed possible? It was much easier to get from Point A to Point B; it was also much easier to end up in a ditch! Used within its designed intentions, the Event Processor can’t help but improve your MIDI experience. Used outside the rules, though, it can sometimes make things very unpredictable. Here’s a brief guide to understand the rules that the Event Processor can’t break ...

 

MIDI BANDWIDTH

MIDI runs at 31.25Kbit/sec., which works out to roughly 1,000 average MIDI commands per second. That sounds like an awful lot of time to send MIDI, but the figure can be deceiving. Certain styles of music -– ex: Hammond Organ techniques like "smears" and "palm glisses" -– require that a lot of notes be struck and released in a very short time, even though the average notes per second throughout the song might not be all that high. Can Joey DeFrancesco or Chester Thompson play faster than one note per millisecond for very short bursts? Sure they can. Can an average PC/Mac sequencer and an 8x8 MIDI interface up the ante? You betcha. Keep this in mind when you consider sending a merge of 4-5 MIDI outputs to one cable, and "let the devices sort it out."

The Event Processor itself is immune to failure due to fully loaded MIDI bandwidth; it’s happy to send 31,250 bits per second. However, the MIDI keyboard may also enter the picture by dropping note information if it receives more notes than it can process. Dropping Note On messages isn’t so bad, especially when there are dozens of them happening at the same time, but missing Note Off messages are big trouble. Some MIDI keyboards handle this better than others; it’s just something to be aware of.

The one thing that can bring the Event Processor to its MIDI ‘knees,’ sooner or later, is data duplication. If the Event Processor is programmed to map several output commands for each one it receives, it’s kind of like pouring buckets of water into a sink with a little drain pipe. The ability to empty the ‘pipe’ has to match the ability to fill it, or ‘sink’ is going to overflow. Although the Event Processor itself can have ‘drainage’ issues under severe cases, the real culprit is usually MIDI itself. The output of the Event Processor can’t be offloaded any faster than 3,125 bytes per second. If you’re playing 64th notes on Channel 1, and the Event Processor is copying each note to Channel 2-16, well, something’s got to give. Even if the Event Processor can keep up with the task of duplicating the notes, they’re being stockpiled faster than MIDI can use them.

The Event Processor uses built-in algorithms to try to thin the data in these cases, but anytime we throw things out, there’s always a chance to throw out the wrong item. And unlike audio information, lost MIDI data sometimes has more serious consequences that a pop or click.

How can you help? Take a look at the kinds of data that your gear is sending, and whether you’re using it or not. Aftertouch is a notorious hog of MIDI bandwidth, often without being used at the receiving end. Sequencer clock data is another area to watch: In many cases, the slave devices are reacting to the MIDI notes sent by the sequencer, and the clock data is simply being thrown away. One of the worst of all is Polyphonic Aftertouch, which can clog the entire bandwidth with the data from a single instrument! All of these troublesome elements can be filtered in the Event Processor.

Additionally, don’t duplicate events "just in case they’re needed." Save the extra Settings for later on –- you’ll find uses for them, I promise!

 

MIDI OVERFLOW

It sounds like the same thing as MIDI Bandwidth, but it’s actually a totally different animal. MIDI Bandwidth is like a clogged pipe; MIDI Overflow is like having too small a bucket at the end of the pipe. MIDI Overflow occurs when the receiving device can’t act on the data as fast as it comes in, even if the actual data fits in the rules of MIDI. This was a huge problem in the early days of MIDI devices, but has kind of faded as CPU power has increased. It still rears up now and then, especially with older or low-cost slave devices. Different devices react to MIDI Overflow in different ways, too: some devices thin the data; some throw out the oldest information; some reject the latest information; and some just lock up. [Ugh!]

The answer to both MIDI Bandwidth and MIDI Overflow problems usually boils down to eliminating some of the data, either by filtering it from the output of the Event Processor; or by reducing the amount of new data that the Event Processor is asked to generate.

In addition, certain kinds of data require extra time to process. This is especially true of Program Change commands, so don’t try to slip one of them in between other events; send them when the MIDI data is less congested. SysEx is another potential culprit. If a particular task can be done with CC commands or SysEx, always reach for the CC approach, since it’s channel-based, and requires less effort to process.

 

DUPLICATE SETTINGS

A Setting can be programmed many times in the Programming Tools, but can only be used once by the Event Processor. The last command for each Setting number is the one that counts. If you create six settings with the same Setting number, the first five of them are overridden by the sixth Setting, and have no effect. If you want to program the Event Processor to act on six different events, make sure that the program calls out six different Setting numbers. This sounds obvious, but it’s easy to lose track of the events when programming a long series of Settings, especially in the Event Processor Plus.

The Programming Tools software tries to help in this regard. When creating a new program using File --> New, the Programming Tools start at Setting #1, and each time we click on OK, the program automatically increments to Setting #2, Setting #3, etc. There are two cases where this automatic numbering is disabled:

  • When editing an existing program (or using an existing program as a template to create a new program), the Setting counter is not automatically incremented, because the software cannot be sure which Settings will be edited. Automatically jumping to the next Setting could create more problems than it solves.

  • If the user manually changes the Setting number before clicking OK, the automatic numbering is disabled for the remainder of the work in the new file. The software assumes that the user has a particular reason to jump around in the Setting numbers, and makes no attempt to ‘outguess’ the programmer.

 

SERIAL VS. PARALLEL PROCESSING

Any processing device -- MIDI or otherwise -- is either a 'serial' processor, a 'parallel' processor, or some combination of the two.

  • If a device takes an input and makes a change in it, then passes the changed signal to the next step, and on and on until the output, it's a serial processor:

  • If a device takes an input signal and splits or duplicates the signal, then processes each of the duplicates before combining them back together, it's parallel processor:

The Event Processor is a parallel event processor. Keep this in mind when doing similar things to Events on different MIDI channels, or to different data types (notes, controllers, etc.). In most cases, each channel or data type must be processed separately by its own Event(s).

As an example, let's say that I want to re-map all CH1 notes to CH3, but only send the top five octaves of MIDI to a synthesizer on CH3. When I map CH1 to CH3 in Setting #1, I can select a range of MIDI notes that matches the five-octave range I want. However, the other notes will still pass through unmodified, because they don't apply to the setting. If I don't want these notes to show up, on CH3 or CH1, I need another Setting to perform the filtering on the other notes.

 

EVENT PROCESSING ORDER

This may be obvious to anyone who programs software for a living, but the Event Processor takes its commands in the order it sees them, period. Unlike some other MIDI Solutions boxes, the Event Processor doesn’t assign a priority level to each Setting. So, it’s first come, first served. When an event comes in, the first Setting on the list gets to work its magic, then the next one down the line, and so on. Most of the time, this has no bearing on how the end result works out, but there are exceptions.

In a complex group of Settings, it’s possible to program the Event Processor to do one thing early in the list, only to counteract the first Setting later down the line. Two of the most important areas to watch this are 1) enabling or disabling rules; and 2) storing Variables. Once a rule is disabled, it gives up its chance to act on any data that is in process in the chain. If we turn it back on at the bottom of the list, it will act on the next round of data, but not on the data already in process. The same thing is true with Variables: If we act on a Variable in Setting #3, but store it in Setting #5, the action will work with the previous stored data, not the current value of the Variable.

Another point to keep in mind is that the data that leaves the Event Processor is stored in a first-in/first-out (FIFO) arrangement. If your intention is to send a Program Change, and then a Volume change, make sure that the Event Processor is programmed to act on events in that order. The Event Processor can’t know that the Volume change at the end of the line is way more important than the Mod Wheel change you sent at the beginning; it treats all instructions as equally important.

A final point to remember is that the order of processing isn’t related to the order that the instructions were entered into the Programming Tools; it’s related to the Setting number assigned to the instruction. Setting #1 always gets executed before Setting #2, regardless of the way the program was written. This requirement is easy to break, because the Programming Tools actually allow Settings to be re-programmed many times in a program, with only the last instruction having any effect on the output. Be careful that the Setting with the lowest and highest numbers correspond to the first and last actions, respectively, that you want the Event Processor to take. A good practice is to always sort your program at the end, cutting and pasting commands so that they are in order. It will be easier to spot problems this way.

 

MISMATCHED VARIABLES AND VALUES

Generally, Value X represents the first data byte in a command, and Value Y represents the second data byte. And generally, each Value maps to the same location from in to out, X --> X and Y --> Y. However, there are some exceptions, especially when mapping between Program Change and Controller Change messages, because the Program Change has no Value Y. There are also cases where swapping the Values results in a very useful function, and is completely intentional. Just keep in mind that the Programming Tools remember the last Value used for a particular purpose, and automatically reuse the same Value the next time the same Setting type is called up. Most of the time, that’s a good thing; sometimes, it’s not. Pay attention to the Value use when programming your Settings.

A similar situation exists with how the Event Processor processes Variables in real time. Each Setting doesn’t have its own set of Variables; the two or eight Variable locations in your Event Processor are shared among all of the Settings. Once Variable 1 is used to save an input value, it should not be reused until the value has been passed off to its appropriate ‘output’ Setting and keeping track of it is no longer necessary. If Setting #1 saves note velocity to Variable 2, and Setting #6 saves Mod Wheel position to the same Variable, the velocity data is erased. If you plan to use that velocity information in Setting #9, it’s too late: the action that the Event Processor takes is now related to the Mod Wheel.

 

‘LOSING’ DATA IN THE TRANSLATION

The Event Processor can convert one type of MIDI information to another, but it can’t really generate data that didn’t exist in the original event. If, for example, we convert Note On messages into Program Changes, we have a choice of whether we want the note number (Value X) or the velocity value (Value Y) to be converted into a program number. In the opposite direction, though, the Program Change’s one piece of data (program number) can’t suddenly turn into both a note number and a velocity. (OK, technically it can, but the end result isn’t often all that useful.) Instead, we must choose a constant output for the note number and map the velocity from the program number, or send constant velocity and map the program number as a specific note. We can also substitute one of the stored Variables for the missing parameter. We just can’t gain a new parameter that didn’t already exist!

 

NOTE NUMBERING VS. NOTE NAMING

This isn't so much of an Event Processor issue as it is a global MIDI situation. MIDI defines 128 notes, ranging from a C two octaves below the lowest C on an 88-note piano, to a G about 1-1/2 octaves above the High C on that same piano. It also defines Middle C to be at note #60 (3Ch). However, the earliest version of the MIDI specification didn't define any naming convention for the notes themselves. Do we call Middle C "C0"? "C3"? Something else?

Three de-facto standards arose in the industry. The first, and perhaps most common, one notes that keyboard music and notation is commonly based on the piano, and written in the key of C. Thus, it numbers the MIDI scale as "C-2" to "G8." This makes the lowest C on the piano C0. This is the notation system used in the MIDI Solutions Programming Tools. (This system is sometimes referred to as the 'Yamaha system', because the largest maker of musical instruments, Yamaha Corporation, follows this convention). Figure 32 shows this numbering system in greater detail.
 

However, two other 'standards' are used by various manufacturers of MIDI hardware and software. Many keyboard manufacturers number the MIDI scale as "C-1" to "G9." This makes the lowest note on an 88-key piano A0, rather than the somewhat confusing A-1 (this notation system is sometimes referred to as the 'Roland system'). And finally, computer music programs often call the lowest C on the MIDI scale C0, thereby eliminating the entire negative-numbering convention. Both of these schemes are also shown in Figure 32.

What does this mean to you, the programmer? It means that while you can always depend on the MIDI note number when programming the Event Processor, the note name is not guaranteed. Be careful when creating keyboard zones, or when using individual Events to map, trigger, or sequence other Events. If the program doesn't seem to be doing what you expected, use a sequencer or other program to look at the actual data being sent, and compare it to the note(s) being programmed in the Event Processor.

 

BUTTONS THAT DON’T SEND MIDI

Just as we cannot gain new MIDI parameters, we can’t coax MIDI information out of a knob or switch that refuses to send any. A common example is a Split or Zone button: Pressing this button may affect future operations of the keyboard –- even drastically -– but the button itself probably generates no MIDI data when it’s pressed. Even if you never use Zone 4 on your master keyboard, there’s probably no direct way to convert the Zone 4 button into Reverb On/Off. Sorry!

 

SCALING AND ROUND-OFF ERRORS

The Event Processor can scale data from one type to another, and can provide both compression and expansion when scaling. The Event Processor doesn't have the ability to scale into anything except integer number, though, so round-off errors are possible when scaling to or from more than two values.

As an example, scaling from a value of 34-35 on CC#12 to another CC always gives the correct value, because there are only two points to map: the beginning value and the end value. What happens if we map three points into a 0-127 range? Well, 128 ÷ 3 = 42.6667, so depending on whether the Event Processor rounds up or down at a particular point, the value is always going to be a little greater or less than the perfect number. The Event Processor has algorithms to minimize the impact of this problem, but be careful when depending on an exact output value when scaling.

Also, be aware that scaling 0-4 into 0-127 isn't scaling four values into 128 (which maps evenly); it's scaling five values, because zero counts as part of the scaling.

 

POWERING THE EVENT PROCESSOR

The Event Processor can get its power from most MIDI Out or Thru jacks on keyboards, sound modules and computer MIDI interfaces. However, be aware that there is no industry standard for self-powered MIDI devices, and not every manufacturer uses the suggested MIDI interface circuits defined in the MIDI standard. If the red LED on your Event Processor refuses to light, chances are that your MIDI cable isn’t providing adequate power.

There are several ways to work around this:

  • Rearrange the order of your MIDI devices so that the Event Processor is connected to a device which can power it. Remember, more than one MIDI Solutions processor can be connected in series to share the power; I’ve found that 2-4 devices can be powered this way under almost all cases.

  • Connect the device that is supposed to drive the Event Processor to another device’s MIDI In port, and then connect that device’s MIDI Thru port to the Event Processor. (The Thru connection produces an exact copy of the In data received.)

  • Purchase a MIDI Solutions Power Adapter directly from MIDI Solutions. In addition to powering several devices, the Power Adapter allows a longer connection than 15 meters (50 feet) between MIDI devices, and improves the reliability of data in moderately long MIDI cables.

 

RECOVERING THE PROGRAMMING DATA

The Event Processor does not support dumping the contents of its memory through the MIDI Out connector. It is important to remember this, and to keep a backup copy of the programming data (the .RTF file) in a safe place. The Event Processor will not ‘lose’ the data once programmed, but if you want to make changes a few months down the road, it will be easier to edit the previous settings than to reprogram the Event Processor from scratch.


 

CLOSING THOUGHTS

Once programmed and used the way it was designed, the Event Processor is truly capable of making changes to your MIDI gear that can only be described as bordering on "magic." The limitations are few; the capabilities are enormous. Keep this guide handy, and refer back to it as you uncover new uses for your Event Processor. MIDI Solutions gear is very rugged: I’ve had some of my boxes for many years, and they still look and work like new.

You’ll probably find that your Event Processor setup starts out kind of plain, but gets more complicated over time. Each new piece of gear that you buy will have certain traits that you really dislike, and the Event Processor will likely come to the rescue each time. This is where the extra Settings and Variables of the Event Processor Plus may make the extra expense well worth it, even if you aren’t using all the capabilities at first.

Enjoy your new toy – make that, tool. In time, I think that you’ll find that, like this author, you can’t imagine not having an Event Processor around to set things right!

-BW
Bruce Wahler

 

Previous Chapter

 

Copyright © 2024 by Ashby Solutions. Used with permission by MIDI Solutions, Inc. This document may be freely copied and distributed in whole; sections of the document may not be used for other purposes without expressed written permission from Ashby Solutions.

MIDI Solutions, the Event Processor, and the Event Processor Plus are trademarks of MIDI Solutions, Inc. of Vancouver, BC, Canada. Ashby Solutions and the Ashby Solutions logo are trademarks of Ashby Solutions of Ashby, MA, USA. All rights reserved.


Products | FAQs | Support | About | Order


Copyright © 2024 MIDI Solutions Inc.