Advanced MIDI (Musical Instrument Digital Interface) . . .
MIDI by the Numbers
The "inner workings" of MIDI is relatively easy to understand once you know the source coding which is employed into this system. Since computers and computerized devices process data at the binary level, a standard "code" was employed to allow the end users to generate messages within this system, as well as to allow these various devices to use the same coding between each other. However, binary (or base 2) numbers can be quite large, consisting of ones and zeros to represent high-level numerical equivalents, whether they are in decimal (base 10) or any other numerical system. This is where "exponential notation" comes into play to help solve this problem. You have the end user on one side of the system who understands decimal numbers, and on the other side is the computer device which is quite comfortable with binary. However, a logical solution to this was already developed way before MIDI was ever conceived. A form of numerical coding which was first used with Bendix computers was later adapted by IBM to form a similar code using the same "base 16" system. But since there are only ten unique digits in decimal (0 - 9), alphabetical characters had to be used for a singular digit to express values from 10 to 15 in decimal. The Bendix system used the last 6 letters of the alphabet, U V W X Y Z, to represent these digits, and then IBM changed that to the first six letters of the alphabet, A B C D E and F to do the same. This system was named "Hexadecimal" (derived from both Greek and Latin to mean "six" and "ten" or together, "16").
Let's take a closer look at these numbering systems. In decimal, we know that our digits are 0 - 9 and that each column represents a power of ten. With any other base, the digits allowed are always one less than the base, so in binary (base 2), we can only use a "1" or a "0" for each digit, and each column other than the "ones column" represents a power of two. The "ones" column is actually 2 to the 0 power since we don't have a power of two. In decimal, we have the ones column expressing values from 0 to 9, and if we add one we now have a power of 10, so each column to the left of the ones column represents a power of ten. We can think of this exponentially (as in scientific notation) as 100 (ones), 101 (tens), 102 (100s), 103 (1000s), . . . and so on. In "Hex", we still have the ones column for values 0 - F (decimal 15), but when we add 1 to F we now have a power of 16 or 10 (Hex), so each column to the left of the ones column represents a power of 16, or 161, 162, 163, etc. Since the base is larger than both binary and decimal, we can represent large numbers from either numbering systems in Hexadecimal with fewer digits, making it very easy to express these numbers or interpret them for the end user.
You can also see this by using your Windows calculator and switching from the "standard mode" to the "scientific mode". You will see selections for Hex (base 16), Decimal (base 10), Octal (base 8), and Binary (base 2). Octal (or base 8) was only used on some select computers, but the other three bases are more commonly used today. The convenience of Hex is that if you can count from 0000 to 1111 (in binary), you can easily translate any large binary number to Hex, using the digits from 0 and F. (See the table below).
| Decimal |
Binary |
Hex |
| 0 |
0000 |
0 |
| 1 |
0001 |
1 |
| 2 |
0010 |
2 |
| 3 |
0011 |
3 |
| 4 |
0100 |
4 |
| 5 |
0101 |
5 |
| 6 |
0110 |
6 |
| 7 |
0111 |
7 |
| 8 |
1000 |
8 |
| 9 |
1001 |
9 |
| 10 |
1010 |
A |
| 11 |
1011 |
B |
| 12 |
1100 |
C |
| 13 |
1101 |
D |
| 14 |
1110 |
E |
| 15 |
1111 |
F |
By grouping the binary digits into 4-bit groups, each group can be represented by a single Hex digit. Thus, a byte of information consists of 8 bits (or two groups of 4 bits each), or two Hex digits. For example, the binary number 0111 1111 equals 7F in Hex. The "7" represents the "Most Significant Bits" (or MSB), and the F represents the "Least Significant Bits" (or LSB). We refer to half of a byte (4 bits) as a "nibble", thus "two nibbles to the byte". The value range for a byte is from 00 to FF, or in binary, 0000 0000 to 1111 1111. That translates in decimal from 0 to 255 (or 256 possible data values).
You can click here for a Decimal To Hexadecimal Conversion Chart (with all 256 possible values for a byte) for use in this discussion. I did not include binary values in this chart since you can easy equate the Hex digits into binary using the previous conversion chart. The left half of the chart will show all "Data Values" for a byte in a MIDI message (00-7F), and the right half will be the values from which "Status Values" have been selected (80-FF) according to the MIDI Specification.
Now all of this is grand for the computer programmer to use, however Dave Smith (President of Sequential Circuits) probably understood the potential of using this numerical system to establish the functionality of the MIDI protocol. The MSB of a byte would be considered the Status part of a MIDI message and the LSB could be used to indicate a MIDI channel with values from 0 to F, or 16 possible MIDI Channels. Following the Status byte, data byte values would range from 0 - 127 (decimal), 0000 0000 - 0111 1111 (binary), or 00 - 7F (Hex). For example, a message to trigger a note would be: 90 3C 40 (in Hex). The "9" is the "Note On Status", followed by "0" representing the MIDI Channel 1 (or n+1). The next byte is the note number in hex, 3C which is "Middle C" (decimal value = 60), and the last byte of the message represents a key velocity of 40, (decimal value 64), which is a medium velocity value. The MIDI Specification will explain these messages in greater detail. To turn that note off, when the key is released, another "note-on" event is transmitted but in this case the velocity value is set to "0". Thus, note-on events can be used to trigger a note on and off using the same status format, totaling 6 bytes per note, (without aftertouch values). With aftertouch, in which further pressure is applied to a key or group of keys, many addtional bytes are sent to reflect this control value to the receiving device, be it a MIDI sequencer (recorder), or a MIDI sound generator. And so, a MIDI sequence containing aftertouch information will be much larger than a sequence which did not record aftertouch values. Depending upon the instrument or MIDI controller, aftertouch can be either "channel aftertouch" in which the greatest amount of aftertouch affects all notes on one particular MIDI channel, or "polyphonic aftertouch" in which each key transmits its own aftertouch value and each notes responds with each aftertouch control, individually.
The Full Range of "MIDI Notes"
The full "MIDI Note Range" is actually larger than the 88-note piano keyboard, extending above and below it to allow for octave shifting or pitch bending of MIDI notes up to about two octaves in either direction, (up or down). Since we have 128 possiblities for our note data, the MIDI spec allows for notes which are actually beyond the physical scale of some virtual instrumentation.
MIDI Keyboard Controllers come in various sizes with varying numbers of notes and octaves. The following chart shows some of this coverage by comparing the full MIDI note range to several MIDI keyboard controllers. In this case, I compared a 4-Octave (49-note) Roland PC-200 MK II MIDI controller, a 5-Octave (61-note) Roland Juno-106 synth, a 76-note Roland KR-500, and a Technics PR-305, 88-note digital ensemble piano. The PC-200 can shift its 5-octaves of "C" range up or down one octave through MIDI at a time. The other keyboards can transpose in half-steps within a certain range, up or down, and octave shift through MIDI, as well. I have arranged the four keyboard controllers in this diagram with the full MIDI scale so that Middle "C" (MIDI note #60, or C4 which means the 4th MIDI Octave of "C") is vertically aligned. You can click on the image below for a larger view as an Adobe Acrobat (.pdf file).
This comparison represents what MIDI notes are transmitted by playing each keyboard. MIDI-note reception ranges may vary with each sound-generating keyboard. Simarly, MIDI-note reception may also vary with each MIDI tone generator in a MIDI setup, so it's a good idea to explore the MIDI implementation chart for each device used when sequencing.
Other channel messages include control changes such as channel volume (MIDI volume), program change (sounds), pitch bend, modulation, sustain pedal values, panning control, channel or polyphonic key pressure (aftertouch), and others. The MIDI data for these controllers generally works in this way: for continuous controllers (such as MIDI volume, panning and parameter sliders), the data range is 0 - 7F (Hex) and the values in-between are considered as each control is varied continuously. For "on" and "off" switches, such as a sustain pedal, only the two extreme values are considered, thus 7F(H) is "On" and 00(H) is "Off" and the in-between values are ignored. So, if you were to manually insert a sustain pedal CC value of 7F in a MIDI sequence, the notes on that channel would sustain until another pedal value of 0 is received. You could also record the action of a continuous controller or parameter edit in real-time within a MIDI sequence, and then look at these values within the sequence to determine their format and function and then edit them manually.
Also, some controllers, such as pitch bend and aftertouch require additional bytes of data which makes it a little more difficult to create manually. However, they do work well when recorded in real-time when transmitted by the actual MIDI controllers. A MIDI sequence will require more bytes for a performance containing aftertouch and pitch bend information from a MIDI keyboard than a keyboard which does not transmit these values, especially with polyphonic aftertouch in which each note transmits its own aftertouch values when its key is depressed with extra force after having been initially struck. But these performance controllers add more depth of expression and realism to a recording with voices such as brass, woodwinds, strings and synth sounds. You would not expect a piano track to have either pitch bending or aftertouch controllers by comparison, even though it might be possible to record such controllers to affect a piano MIDI track.
Besides channelized messages, MIDI offers channel mode messages, system common messages (such as a tune request), and system Real-Time messages which control song-playback parameters such as "start", "stop" and "continue" for a MIDI "song", timing clock, reset back to measure 1, etc. System Exclusive messages allow transmission and reception of bulk data, parameter changes, and much more. To prevent devices from translating data which is not intended for them, the use of manufacturer, model and device ID codes were established for each company, device and model. You can look up the specifics for each device as indicated by the MIDI Implementation Charts which are supplied by each manufacturer. These charts indicate the details as to what messages are transmitted and recognized, and other MIDI specifications, and may express these values in either binary, hex or decimal.
Typical MIDI Scenarios
When MIDI was originally adopted by the industry, keyboardists were delighted to find that they could connect two MIDI synthesizers together and trigger both from the master keyboard (known as MIDI layering). This was quite an improvement over the earlier control voltage method of note triggering which often resulted in "stuck notes" and other undesirable effects. Eventually, the first MIDI sequencers were introduced and they were typically 2-track recorders with limited memory capability and functions. But in time, these stand-alone sequencers became more sophisticated and allowed the user to mix tracks, edit notes and other data, and perform a variety of song-composition tasks. The standard MIDI clock on the sequencer could be synched to a drum machine and either one device could regulate the timing of the other.
Click here for a diagram of some basic MIDI setups for performance and recording.
Eventually, the synth manufactures developed MIDI sound modules to add additional sounds for either performance or recording purposes. As the sound-generation technology became more sophisticated, the musical realism of a MIDI sequence greatly improved. Computer sequencing software developed in time, as well, to allow composers to graphically view and edit a variety of recorded MIDI events and messages.
Today, computers function as MIDI seqencers, data and voice librarians for sound modules, keyboards or drum machines, and advanced digital processing which may include sound generation, digital sampling, mixing, notation, effects generation and more. The concept of continuous controller values can be used to control animation effects and even stage lighting production. In time, the MIDI protocol has not changed as much as the various uses for it in the music industry. The development of alternative MIDI controllers has enabled other musicians to enjoy the benefits of MIDI, as well as keyboardists. Several manufactures developed electronic wind instruments (EWI), MIDI guitars and other types of MIDI controllers which could now accurately transmit stable MIDI note messages from non-keyboard controllers to sound generators for this purpose.
MIDI sound modules or tone generators became "multi-timbral" devices which could assign various sounds to individual parts, thus allowing for a complete musical performance from just one of these devices. The classic examples of these were the Roland SC-55 "Sound Canvas" which was small and portable, but offered a complete range of sounds (including percussion and sound effects) over 16 MIDI channels. Yamaha offered a similar device starting with the TG-1 and MU50 series.
It became obvious that a standard for voice assignments would help unify MIDI sequences so that they would sound appropriately when played on a different systems. Roland and other manufacturers agreed upon the Standard MIDI File convention, (SMF), which assigned the same basic sounds for conventional program change commands. It also suggested that drum parts be assigned to channel 10 within this standard, however the user could still choose to assign additional drum parts or sounds on other channels. Thus, the observance of this format was generally recommended for sake of conventional, but not necessarily an absolute requirement for all MIDI sequences. The "down side" of this format was a limited range of 128 "primary tonal instruments" plus drums, even though there are many other alternate sounds available for use on various multi-timbral modules and keyboards. The "plus side" was that if I selected a piano sound with a program change value of "1" for Part 1 of my MIDI sequence, then playback on another system would select a similar type of piano sound for the same part.
Prior to this convention, Roland was generally assigning drum parts to MIDI Ch. 10, and Yamaha was using Ch. 16 (especially on Clavinovas, DOM-30 "Disk Orchestra" modules, TG-100 tone generators, and Electone Organs). Other companies (such as Korg) were assigning drum parts on just about any channel the user chose. You could quickly tell this when you heard a piano sound trying to respond to note messages intended for drums. . . a rather "noisy" scenario. At the very least, the SMF convention helped to correct this problem and allow for a more universal system of MIDI recording and performance for global distribution purposes. Later-on, the use of "SMF" files for karaoke use was added to the convention as a "Type-0 SMF" which included embedded lyrics on their own MIDI track. These were then displayed through video monitors on playback with the help of a device which decoded these lyrics and highlights each word as they were played within the MIDI sequence. SMF MIDI Files without lyrics are known as "Type-1". If you want to have lyrics displayed on a MIDI device with a known display address, I will discuss how you can achieve this in a moment with System Exclusive Messages.
Program Changes
Early synths and modules, such as the Roland JUNO-106 and others, conveniently had 128 programs (or sounds) to select for playing or recording through MIDI. These were usually arranged as two groups (Group A and B) of 64 programs for each group, and 8 banks with 8 programs for each bank, or 128 sounds in total. When more than 128 sound programs were included in a keyboard or MIDI sound module, this exceeded the normal range for a standard program change command within the 00-7F data range. One solution to this problem was to allow the end user to create a program change map (essentialy, a memory buffer or array to assign programs from higher banks to correspond to a basic program change message of 128 possible numbers). In that scenario, a program change of "1" might call up a program from the 5th bank, sound number 30, thus two bytes of data would be stored in the first program change address to call up this program.
A sound module I recall which had this feature was the Yamaha TX81Z which had a user-assignable program change map. Eventually, the MIDI Spec. allowed for a "Bank Select" command to accompany a program change command to select sounds from program banks exceeding the standard 128 sounds. For MIDI sequences which have such commands, they are not considered as true SMF or General MIDI format since the results may be different on various tone generators. However, it does allow the user to specify alternative sounds within the MIDI sequence for their own use and proper playback. For this reason, again, General MIDI and Standard MIDI Files are only considered to be a "convention" and not an "absolute" requirement to MIDI sequencing in all instances. The end user can choose to create a SMF MIDI sequence file for distribution purposes, or create a custom MIDI file for just their own use for recording or performance.
In either case, it's always a good idea to keep a "MIDI Track Production Sheet" printout for each MIDI sequence. On this, you would indicate the programs used on all 16 MIDI channels, and some setup notes about specific channels or tracks so that you can recreate the setup at a later date. You might want to indicate what sound module was used and any other custom details, such as mixer levels, EQ, effects, etc. As always, the more documentation, the better!
Dynamic Voice Allocation and Voice Reserve
Many multi-timbral sound modules reserve the most amount of voices for piano and drum parts to avoid "note-robbing". For this reason, most MIDI sequences have the piano part recorded on MIDI Channel 1 (and Ch. 2 for a split-piano performance). The idea of this is that we don't want to lose piano notes in favor of a secondary instrument on another channel (which might happen as you approach the voice-limitation of the sound module). Voice Priority in the Genral MIDI format is usually assigned as follows:
MIDI CH. 1 (Piano)
MIDI CH. 10 (Drums)
CH. 2
CH. 3
CH. 4
CH. 5
CH. 6
CH. 7
CH. 8
CH. 9
CH. 11
CH. 12
CH. 13
CH. 14
CH. 15
I usually assign MIDI Channels 1 and 2 for keyboard parts, Ch. 10 for drums, Ch. 3 for bass, and then build the remainder of my instrumentation upwards sequentially by channel number for additional instruments as they are needed (Guitar, Strings, Brass, Woodwinds, etc.). As you can see, the lower the channel number, (with the exception of MIDI Ch. 10), the higher the priority is assigned for those voices. In some cases you can alter this priority, but in general, it's a good thing to keep in mind, especially with modules with limited voice capacities. For SMF sequences with just piano parts, the convention is usually on Ch. 1 or, Channels 1 and 2 (if the treble and bass clefs are assigned individual MIDI Channels).
System Exclusive Messages
By definition, System Exclusive messages are intended to be sent to and from specific MIDI devices. These messages could be changes in specific parameters, system functions, or even a complete data dump containing all of the programmable information for a singular device. The obvious benefits of this is the ability to store this information on an external device, such as a personal computer or hard drive, and to allow for computer software to functions as "data librarians" and "voice editors". Even the end user can generate such messages and embed them into a MIDI song sequence, but it requires just a little knowledge of the MIDI implementation for that specific device. For this purpose, the manufactures included the format for these commands in their owners manual, in addition to the "MIDI Implementation Chart" which briefly describes which type of messages these devices transmit and receive.
Some vital components which prevents a device from interacting with data that is not intended for it are: 1) the MIDI Manufacturer ID Number, 2) the Model ID, 3) the Device ID, and 4) model-specific "data hand-shaking." When the MIDI Specification was first introduced, each MIDI manufacturer was assigned an official MIDI Manufacturer ID Number upon their application. This would prevent devices from another company from responding to data which was intended for another. Some examples of these are:
| ID Number | MIDI Manufacturer |
| 40H | KAWAI |
| 41H | ROLAND CORP. |
| 42H | KORG INC. |
| 43H | YAMAHA CORP. |
| 44H | CASIO |
As more companies applied, the ID number expanded into a three-byte number for assignment. The Model ID number would exclude the interaction of different devices from the same manufacturer other than the intended device. Also, the MIDI Manufacturers Association (MMA) encourages all MIDI manufacturers to publish their System Exclusive Formats so that the end user can constructively utilize them. In the case where two of the exact same devices exist in a MIDI system, the user could assign a different device ID for each, thus isolating one device and data set from another. (The default is usually device number 10H when not changed by the user.)
The "data handshake" I mentioned earlier essentially consists of a "digital conversation" between two devices before the transmission and reception of data proceeds. It would be like two people conversing in this manner:
Q. "Hey, what make and model are you?"
A. "I'm a Yamaha HX1 Electone Keyboard."
Q. "I have a bulk data set to send to you, are you ready to receive it?"
A. "Okay, I'm ready to receive that... send it along!"
The dialogue might continue as each data packet is sent and received with a confirmation at the end that all of the data was transmitted and received successfully. If not, then an error message would be generated, usually on the receiver's side. In the case where either the ID, model or device code would not match, then the data would not be transmitted, and/or there might be a data error message displayed accordingly.
System Exclusive Message Example
Let's explore a system exclusive command scenario. . . In this case, I would like to send a Sys-Ex message from my sequencer to my Yamaha MU50 tone generator to display some characters on the system's front panel display. The computer industry has adopted the ASCII standard of assigning data values for alphanumeric characters. Using just 7 bits for this data, values from 0-127 (dec) or 00-7F (hex) have been assigned to each character on the ASCII table. The "extended ASCII character set" ranges from 128-255 (dec), or 80-FF (hex) and is used for European accents and special graphical characters. From the basic character set, the first 32 values (0-31) are reserved for non-printing functions, while the remaining byte values 32 (dec) to 127 (dec) are assigned to the characters we will use in this example. The following standard ASCII character chart will be used.
| Dec |
Hex |
Ch. |
Dec |
Hex |
Ch. |
Dec |
Hex |
Ch. |
| 32 | 20 |
Sp. | 64 |
40 | @ |
96 | 60 |
` |
| 33 | 21 |
! | 65 |
41 | A |
97 | 61 |
a |
| 34 | 22 |
" | 66 |
42 | B |
98 | 62 |
b |
| 35 | 23 |
# | 67 |
43 | C |
99 | 63 |
c |
| 36 | 24 |
$ | 68 |
44 | D |
100 | 64 |
d |
| 37 | 25 |
% | 69 |
45 | E |
101 | 65 |
e |
| 38 | 26 |
& | 70 |
46 | F |
102 | 66 |
f |
| 39 | 27 |
' | 71 |
47 | G |
103 | 67 |
g |
| 40 | 28 |
( | 72 |
48 | H |
104 | 68 |
h |
| 41 | 29 |
) | 73 |
49 | I |
105 | 69 |
i |
| 42 | 2A |
* | 74 |
4A | J |
106 | 6A |
j |
| 43 | 2B |
+ | 75 |
4B | K |
107 | 6B |
k |
| 44 | 2C |
, | 76 |
4C | L |
108 | 6C |
l |
| 45 | 2D |
- | 77 |
4D | M |
109 | 6D |
m |
| 46 | 2E |
. | 78 |
4E | N |
110 | 6E |
n |
| 47 | 2F |
/ | 79 |
4F | O |
111 | 6F |
o |
| 48 | 30 |
0 | 80 |
50 | P |
112 | 70 |
p |
| 49 | 31 |
1 | 81 |
51 | Q |
113 | 71 |
q |
| 50 | 32 |
2 | 82 |
52 | R |
114 | 72 |
r |
| 51 | 33 |
3 | 83 |
53 | S |
115 | 73 |
s |
| 52 | 34 |
4 | 84 |
54 | T |
116 | 74 |
t |
| 53 | 35 |
5 | 85 |
55 | U |
117 | 75 |
u |
| 54 | 36 |
6 | 86 |
56 | V |
118 | 76 |
v |
| 55 | 37 |
7 | 87 |
57 | W |
119 | 77 |
w |
| 56 | 38 |
8 | 88 |
58 | X |
120 | 78 |
x |
| 57 | 39 |
9 | 89 |
59 | Y |
121 | 79 |
y |
| 58 | 3A |
: | 90 |
5A | Z |
122 | 7A |
z |
| 59 | 3B |
; | 91 |
5B | [ |
123 | 7B |
{ |
| 60 | 3C |
< | 92 |
5C | \ |
124 | 7C |
| |
| 61 | 3D |
= | 93 |
5D | ] |
125 | 7D |
} |
| 62 | 3E |
> | 94 |
5E | ^ |
126 | 7E |
~ |
| 63 | 3F |
? | 95 |
5F | _ |
127 | 7F |
DEL |
The owners manual tells me that I can send a Sys-Ex message to the system address: 06 00 00 including ascii values up to 20(H) (32 bytes of data) and select characters from 20 - 7F(H) which are those on the previous chart. The first byte will be the System Exclusive status byte "F0" (which is not channelized), followed by the manufacturer MIDI ID code for Yamaha "43" (H), then the device number "10" (H), model number "4C" (for the MU50), the base address 06 00 00, the ascii data bytes, and end with a F7 (a.k.a. EOX or, End Of Transmission) to indicate the end of the message. The first 16 bytes of data will be the top line on the display and the remaining 16 will be the bottom line of the character area on the display. The whole message will look like this:
F0 43 10 4C 06 00 00 20 20 20 20 54 48 49 53 20 49 53 20 20 20 20 20 20 20 20 20 41 20 54 45 53 54 21 20 20 20 20 20 F7
When sent, the screen will display this for about the duration of a measure at 120 bpm (about 4-5 seconds):
| _ | _ |
_ | _ |
T | H | I | S |
_ | I | S |
_ | _ |
_ | _ |
_ |
| _ | _ |
_ | _ |
A | _ |
T | E | S | T |
! | _ |
_ | _ |
_ | _ |
I can also send a single character to a relative address from the base. For example, the last character element address on the top line would be at: 06 00 0F.
Another use of the character area would be to insert song lyrics in ascii to appear in time with the song's melody, thus creating a sort of karaoke MIDI sequence. I have done this with the Yamaha MU50, the Roland MT-32 and the Sound Canvas (Roland SC-55) since the display addresses are listed in the MIDI implementation sections of the owners manuals.
There is also a bitmapped area on the MU50's display which I can address by turning bits on or off at address 07 00 00. Each binary bit represents a pixel block in a dimensional array of 16 x 16. That one is a little bit more complex since I have to map out my bits in order to establish the hex data required. To make that easier, I created a template or worksheet as a grid where each block represents either an "on" or "off" bit (a "1" or a "0"). Once I have filled-in the bits I need, I then just need to convert those binary blocks into hex bytes for my System Exclusive data string.
Let's examine this process, which is a good exercise in working with blocks of data within a matrix (or array). The owners manual tells me that this bitmapped area is 16 column blocks (or pixels) wide by 16 rows which they have divided into three sections. The first two sections are 7 pixels wide by 16 rows, and the last section (the last two columns in the array) is just two pixels by 16 rows. Each pixel of each row in the first two sections correspond to the 7 least siginificant bits of a byte with the most significant bit being ignored. Thus, the value of that byte can be anywhere between x000000 and x1111111 (or 00 to 7F (hex). So, the bits are numbered from right to left as follows:
b6 b5 b4 b3 b2 b1 b0
The last column still requires a full byte to process each row, but since there are only two pixels to trigger on or off, only bits b5 and b6 are processed from each byte sent.
byte # b6 b5 b4 b3 b2 b1 b0
| d0 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d1 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d2 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d3 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d4 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d5 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d6 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d7 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d8 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d9 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d10 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d11 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d12 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d13 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d14 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d15 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
|
byte # b6 b5 b4 b3 b2 b1 b0
| d16 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d17 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d18 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d19 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d20 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d21 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d22 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d23 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d24 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d25 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d26 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d27 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d28 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d29 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d30 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
| d31 | 1 |
1 | 1 |
1 | 1 |
1 | 1 |
|
b6 b5
| d32 | 1 |
1 |
| d33 | 1 |
1 |
| d34 | 1 |
1 |
| d35 | 1 |
1 |
| d36 | 1 |
1 |
| d37 | 1 |
1 |
| d38 | 1 |
1 |
| d39 | 1 |
1 |
| d40 | 1 |
1 |
| d41 | 1 |
1 |
| d42 | 1 |
1 |
| d43 | 1 |
1 |
| d44 | 1 |
1 |
| d45 | 1 |
1 |
| d46 | 1 |
1 |
| d47 | 1 |
1 |
|
(The "byte #" column is just for reference to the data byte numbers of d0 to d47). With this chart, you can now graphically see where each bit will either turn on a pixel with a "1" or turn it off with a "0". The format of the Sys-Ex message will be:
F0 43 10 46 07 00 00 (48 data bytes - d0 to d47) F7
The accepted values for d0 - d31 will be anything from 00 to 7F, and the processed values for the last column (d32 - d47) will be either 00, 20, 40, or 60. 00 will turn off all bits in this column, 20 will turn on the right pixel and turn off the left, 40 will turn on the left pixel and turn off the right, and 60 will turn on both pixels in this column. In binary these byte values would be: 00000000, 00100000, 01000000, and 01100000, and only bits 5 and 6 will be considered by the system.
Checksums And How To Calculate Them
The checksum, (also known as the "Roland Checksum"), is another method used to prevent the processing of bulk data which is not "signed" with an appropriate value to confirm the authenticity of such data. Provided that the ID code, model code, device ID, and other codes in the header of an exclusive message are correct, we now have to signify that the address and data being sent is "authentic" and should be processed by the receiving device. An example of the basic message format would be:
H e a d e r -- Address -- Data -- Checksum -- EOX
or,
F0 41 10 42 12 (Address) (data string) Checksum F7
In this example, F0 is the Sys-Ex status type, 41 is the Roland MIDI Manufacturer ID number, 10 is the device ID number, 42 is the model number, and 12 is the command code for data transmission. The address will be a three-byte number followed by a string of data bytes, then the checksum, and finally, the F7 or EOX (End Of Transmission) byte. In order to arrive at the checksum, we only need to be concerned with the address and the data bytes. In essence, the sum of the (address + data) is reduced by either divsion or subtraction with 80 (H) until there is a remainder which is less than 80 (H). The "Two's Complement" of that remainder will be our checksum. Another way to look at this is that if we were to consider the remainder ("R") in binary (for ex., 0100 0000), reverse the bits to make 1011 1111, and then add 1, you would have 1100 0000. We ignore the most significant bit since that indicates a number greater than 80, and you are left with 0100 0000, or 40 (H) as your checksum.
It is probably easier just to think of this as: 80 - R = Checksum. By "Two's Complement", we mean that this a number which added to the remainder to make "1" in the Most Siginificant Bit (or, 80). When you send the data, the receiving device will calculate the checksum according to the address and data specified in your Sys-Ex message and compare it against your's. If they match, then the receiving device will accept and store the data at that address. If they don't match, then you will get a "checksum error" message and the Sys-Ex message will be ignored or not processed. This also works in the sense that an address of 00 00 00 plus 00 data would require a checksum of 80 (which is not allowed), thus, "zero address and data means do not process any data." The only valid data values for a checksum would be from 01 to 7F. You can use your Windows calculator in the "Scientific Mode" (in the Hex mode) to calculate your remainder, and then, your checksum.
Real-Time Parameter Edits
You can use real-time parameter edits to change the nature of a sound during a MIDI-sequenced performance. This is easily achieved from a MIDI keyboard or synth which can transmit a change in any given parameter while recording this information. I first discovered this on my Roland Juno-106 synth when I moved a parameter slider in real-time while I was recording. Each movement of the slider was recorded as a new parameter change event (System Exclusive Message) into the sequence. After I made this recording, I could then examine the data in my sequence which would tell me the exact parameter values recorded, and also allow me to edit these if I wanted to vary the effect of the sound edit. This process added another dimension to making music in that I could vary the nature of the sound being played, besides just triggering this sound with just key events. It could even be just one note, held for a long duration, but having a change in a filter or some other modulation of the sound during the length of the sustained note.
Pseudo-Automated MIDI Mixing
Many other gradual changes can be recorded into the sequence. You can record your own MIDI volumes in real-time for each individual MIDI channel. This is sort of like extablishing your own "master mix" for each part and is a form of "Pseudo-Automated Mixing". Instead of mixing volume levels on a conventional mixer, you are now creating the same effect within the MIDI sequence itself. You can also record changes in panning (left to right or vice versa) of individual parts, rather than doing this manually on the mixer which would require separate audio channels for each part. By recording these elements into the MIDI sequence, the output of the device can then run in stereo on just two audio channels on your mixer or amplifier, but your automated mixing will remain just as effective as with conventional mixing.
Connecting MIDI Devices to a Personal Computer
Perhaps you might want to use the MIDI section of your computer's sound card as a tone generator for MIDI sequences. Or, you might wish to edit your MIDI keyboard or tone generators with computer software. These and other computer-based functions will require a MIDI Interface for connection with your external MIDI components, such as the M-Audio MIDISPORT 2x2 USB, (pictured below). This device features two MIDI IN and MIDI OUT ports and connects to the Mac or PC with a USB cable. Four LEDs display MIDI activity on all ports and another gently pulsates to show that it is properly USB-enabled.
All of these options (and more) open up new ways to express musical compositions with the power which MIDI can provide. You are only limited by the extent of your own imagination!
For more information on the MIDI Specification, visit the web site of The MIDI Manufacturers Association at: http://www.midi.org
Mark Prigoff
Digital Jazz Productions
June 2006
© 2003-2008 Mark Prigoff, Digital Jazz Productions
Contact: Mark Prigoff
