Section 4. Supplementary material

Decimal and Hexadecimal table

In MIDI documentation, data values and addresses/sizes of exclusive messages etc. are
expressed as hexadecimal values for each 7 bits.
The following table shows how these correspond to decimal numbers.
+——————+——————++——————+——————++——————+——————++——————+——————+
| Dec.| Hex.|| Dec.| Hex.|| Dec.| Hex.|| Dec.| Hex.|
+——————+——————++——————+——————++——————+——————++——————+——————+
| 0 | 00H || 32 | 20H || 64 | 40H || 96 | 60H |
| 1 | 01H || 33 | 21H || 65 | 41H || 97 | 61H |
| 2 | 02H || 34 | 22H || 66 | 42H || 98 | 62H |
| 3 | 03H || 35 | 23H || 67 | 43H || 99 | 63H |
| 4 | 04H || 36 | 24H || 68 | 44H || 100 | 64H |
| 5 | 05H || 37 | 25H || 69 | 45H || 101 | 65H |
| 6 | 06H || 38 | 26H || 70 | 46H || 102 | 66H |
| 7 | 07H || 39 | 27H || 71 | 47H || 103 | 67H |
| 8 | 08H || 40 | 28H || 72 | 48H || 104 | 68H |
| 9 | 09H || 41 | 29H || 73 | 49H || 105 | 69H |
| 10 | 0AH || 42 | 2AH || 74 | 4AH || 106 | 6AH |
| 11 | 0BH || 43 | 2BH || 75 | 4BH || 107 | 6BH |
| 12 | 0CH || 44 | 2CH || 76 | 4CH || 108 | 6CH |
| 13 | 0DH || 45 | 2DH || 77 | 4DH || 109 | 6DH |
| 14 | 0EH || 46 | 2EH || 78 | 4EH || 110 | 6EH |
| 15 | 0FH || 47 | 2FH || 79 | 4FH || 111 | 6FH |
| 16 | 10H || 48 | 30H || 80 | 50H || 112 | 70H |
| 17 | 11H || 49 | 31H || 81 | 51H || 113 | 71H |
| 18 | 12H || 50 | 32H || 82 | 52H || 114 | 72H |
| 19 | 13H || 51 | 33H || 83 | 53H || 115 | 73H |
| 20 | 14H || 52 | 34H || 84 | 54H || 116 | 74H |
| 21 | 15H || 53 | 35H || 85 | 55H || 117 | 75H |
| 22 | 16H || 54 | 36H || 86 | 56H || 118 | 76H |
| 23 | 17H || 55 | 37H || 87 | 57H || 119 | 77H |
| 24 | 18H || 56 | 38H || 88 | 58H || 120 | 78H |
| 25 | 19H || 57 | 39H || 89 | 59H || 121 | 79H |
| 26 | 1AH || 58 | 3AH || 90 | 5AH || 122 | 7AH |
| 27 | 1BH || 59 | 3BH || 91 | 5BH || 123 | 7BH |
| 28 | 1CH || 60 | 3CH || 92 | 5CH || 124 | 7CH |
| 29 | 1DH || 61 | 3DH || 93 | 5DH || 125 | 7DH |
| 30 | 1EH || 62 | 3EH || 94 | 5EH || 126 | 7EH |
| 31 | 1FH || 63 | 3FH || 95 | 5FH || 127 | 7FH |
+——————+——————++——————+——————++——————+——————++——————+——————+
* Decimal values such as MIDI channel, bank select, and program change are listed as
one(1) greater than the values given in the above table.
* A 7-bit byte can express data in the range of 128 steps. For data where greater precision
is required, we must use two or more bytes. For example, two hexadecimal numbers aa
bbH expressing two 7-bit bytes would indicate a value of aa x 128 + bb.
* In the case of values which have a +- sign, 00H = -64, 40H = +- 0, and 7FH = +63, so that
the decimal expression would be 64 less than the value given in the above chart. In the
case of two types, 00 00H = -8192, 40 00H = +- 0, and 7F 7FH = +8191. For example if aa
bbH were expressed as decimal, this would be aa bbH - 40 00H = aa x 128 + bb - 64 x
128.
<Example 1> What is the decimal expression of 5AH ?
From the preceding table, 5AH = 90
<Example 2> What is the decimal expression of the value 12 34H given
as hexadecimal for each 7 bits?
From the preceding table, since 12H = 18 and 34H = 52
18 x 128 + 52 = 2356

Examples of actual MIDI message

<Example 1> 92 3E 5F
9n is the Note-on status, and n is the MIDI channel number. Since 2H = 2, 3EH = 62, and
5FH = 95, this is a Note-on message with MIDI CH = 3, note number 62 (note name is D4),
and velocity 95.
<Example 2> C9 20
CnH is the Program Change status, and n is the MIDI channel number. Since 9H = 9 and
20H = 32, this is a Program Change message with MIDI CH = 10, program number 33 (33 -
SockHop).
<Example 3> EA 00 28
EnH is the Pitch Bend Change status, and n is the MIDI channel number. The 2nd byte
(00H=0) is the LSB and the 3rd byte (28H=40) is the MSB, but Pitch Bend Value is a signed
number in which 40 00H ( = 64 x 128 + 0 = 8192) is 0, so this Pitch Bend Value is
28 00H - 40 00H = 40 x 128 + 0 - (64 x 128 + 0) = 5120 - 8192 = -3072
<Example 4> B3 64 00 65 00 06 0C 26 00 64 7F 65 7F
BnH is the Control Change status, and n is the MIDI channel number. For Control
Changes, the 2nd byte is the control number, and the 3rd byte is the value. In a case in
which two or more messages consecutive messages have the same status, MIDI has a pro-
vision called “running status” which allows the status byte of the second and following
messages to be omitted. Thus, the above messages have the following meaning.
(B3 64 00 MIDI ch.4, lower byte of RPN parameter number: 00H
(B3) 65 00 (MIDI ch.4) upper byte of RPN parameter number: 00H
(B3) 06 0C (MIDI ch.4) upper byte of parameter value: 0CH
(B3) 26 00 (MIDI ch.4) lower byte of parameter value: 00H
(B3) 64 7F (MIDI ch.4) lower byte of RPN parameter number: 7FH
(B3) 65 7F (MIDI ch.4) upper byte of RPN parameter number: 7FH
In other words, the above messages specify a value of 0C 00H for RPN parameter number
00 00H on MIDI channel 4, and then set the RPN parameter number to 7F 7FH.
RPN parameter number 00 00H is Pitch Bend Sensitivity, and the MSB of the value indi-
cates semitone units, so a value of 0CH = 12 sets the maximum pitch bend range to +- 12
semitones (1 octave). (On GS sound sources the LSB of Pitch Bend Sensitivity is ignored,
but the LSB should be transmitted anyway (with a value of 0) so that operation will be cor-
rect on any device.)
Once the parameter number has been specified for RPN or NRPN, all Data Entry messages
transmitted on that same channel will be valid, so after the desired value has been trans-
mitted, it is a good idea to set the parameter number to 7F 7FH to prevent accidents. This is
the reason for the (B3) 64 7F (B3) 65 7F at the end.
It is not desirable for performance data (such as Standard MIDI File data) to contain many
events with running status as given in <Example 4>. This is because if playback is halted
during the song and then rewound or fast-forwarded, the sequencer may not be able to
transmit the correct status, and the sound source will then misinterpret the data. Take care
to give each event its own status.
It is also necessary that the RPN or NRPN parameter number setting and the value setting
be done in the proper order. On some sequencers, events occurring in the same (or consec-
utive) clock may be transmitted in an order different than the order in which they were
received. For this reason it is a good idea to slightly skew the time of each event (about 1
tick for TPQN=96, and about 5 ticks for TPQN=480).
* TPQN : Ticks Per Quarter Note

Example of an Exclusive message and calculat-

ing a Checksum

Roland Exclusive messages (RQ1, DT1) are transmitted with a checksum at the end (before
F7) to make sure that the message was correctly received. The value of the checksum is
determined by the address and data (or size) of the transmitted exclusive message.

How to calculate the checksum

(hexadecimal numbers are indicated by ‘H’)
The checksum is a value derived by adding the address, size and checksum itself and
inverting the lower 7 bits.
Here’s an example of how the checksum is calculated. We will assume that in the exclusive
message we are transmitting, the address is aa bb cc ddH and the data or size is ee ff gg
hhH.
aa + bb + cc + dd + ee + ff + gg + hh = sum
sum / 128 = quotient ... remainder
128 - remainder = checksum
(However, the checksum will be 0 if the remainder is 0.)
<Example 1> Setting Shell depth of snare drum in drum kit 1 to 3.5”.
According to the “Parameter Address Map”, the Drumkit No.1 has an address of 01 00 00
00H, Trigger 2 has a offset address of 02 00H and Shell depth has a offset address of 32H.
Thus,
01 00 00 00
02 00
+) 32
01 00 02 32
MIDI implementation
163
Appendices