Home -> Magazines -> Issues -> Articles in this issue -> View

## MIDI Matters (Part 5) | |

## Back To Basics |

*Final Part: Jay Chapman wraps up his 'Back To Basics' mini-series with a handy recap of bits, bytes and hexadecimal.*

What follows is the final article under the Back To Basics byline. This is not to say that we have covered every MIDI subject under the sun but rather acknowledges the fact that some subjects are more complex than others and don't really fit easily under the 'Basics' banner. Hopefully, 'MIDI Matters' will take on some of the more complex stuff in later articles when you will have had a chance to absorb and experiment with the knowledge that this mini-series of five articles has presented. For the moment we will finish off with a subject area that is not a favourite for many musicians...

This month's article concentrates on the nasty mathematics that you need to take onboard to have a *full* understanding of MIDI. It is unfortunate that MIDI is as much to do with computers (at least 'internally') as music but that's the way it is. So, you need to bite the bullet and get into bits, bytes and hexadecimal. That way, when you read the detailed specification of your latest synthesizer, the section on MIDI implementation will hopefully make a bit (pun intended) more sense. I know this is a pain - but, like medicine, this will be good for you even if it tastes foul while it is going down!

Like most computer systems, your MIDI-equipped synthesizer spends a great deal of its time manipulating numbers. Some of these numbers get sent across the MIDI cable when one synthesizer controls another. If, for any reason, you need to look at these numbers - to compare what your device is doing with what it is *supposed* to be doing, for example - you will need to understand how these numbers are formed and how they are usually displayed. In the MIDI documentation they are often displayed in hexadecimal, and this is why you have to suffer!

The word 'bit' is a contraction of the two words 'binary digit' and for some reason it frightens non-computer people. Having said that, most people are used to dealing with 'decimal digits' on an everyday basis (you know: 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9) and use them quite happily, eg. 123,456,789 is a very large whole number that isn't likely to frighten you unless it's the size of your overdraft! We use these symbols with ease because we have had a lot of practice from an early age with the concept of decimal mathematics - basically, counting in tens.

When we want to transmit our MIDI messages across a MIDI cable, the idea of having ten digits causes a problem since it is difficult (read 'more expensive') to detect ten different states on one *circuit* - which is all we have in a MIDI cable. It is easy ('cheaper') to detect two states - such as 'there IS a current flowing' or 'there IS NOT a current flowing' - so that is what MIDI does. Decimal is 10, binary is 2; hence 'binary digit' and 'bit'.

In decimal, 0 is the lowest value digit and 9 is the highest. If we want to make up numeric values larger than 9 we have to group several digits together and each column (moving to the left) has a larger value. For example, the number 123 means 1 x 100 added to 2 x 10 added to 3 x 1. Binary involves exactly the same messing about but with fewer digits: we only have a lowest (0) and a highest (1). This makes life a lot easier in some respects (although a lot less familiar!) and more complex in others.

For example, the decimal number 511 is represented by just *three* digits in decimal but with no less than *nine* in binary! The actual representation of decimal 511 in binary is 111111111, meaning 1 x 256 + 1 x 128 + 1 x 64 + 1 x 32 + 1 x 16 + 1 x 8 + 1 x 4 + 1 x 2 + 1. Note that in decimal the columns increase by a factor of 10 as you move to the left (1, 10, 100, 1000, etc) whereas in binary they increase by a factor of 2 (1, 2, 4, 8, etc).

The microprocessor inside your MIDI-equipped instruments doesn't usually play with just one bit at a time. In fact, it would be typical if eight bits were handled at a time in a unit known as a *byte*. Within one byte, therefore, we can have every possible combination of its constituent eight bits - from all off, 00000000, to all on, 11111111. There are 256 patterns in all. If we care to enumerate these patterns in the obvious way (corresponding to the decimal: 0, 1, 2, 3, ... 126, 127, 128, ..., 254, 255) we get 00000000, 00000001, 00000010, 00000011, ... 01111110, 01111111, 10000000, ..., 11111110, 11111111 which we can use to represent (amongst other things) the decimal numbers 0 through to 255 (eg. decimal 0 is binary 00000000, decimal 128 is 10000000 and decimal 255 is 11111111).

Remember that we said that it is cheaper to detect one of only two states on our MIDI cable? Well, using binary, we can transmit any numeric value as a string of bits, each of which *can only be* in one of two states. As we have already seen in previous articles, MIDI sends messages which are often made up of several bytes, each byte of which is made up of eight bits.

In general, human beings do things in a way that makes life easier rather than harder and this is exactly the case with the use of the hexadecimal (hex, for short) numbering system in connection with MIDI. Quite often, we are interested in the actual bit pattern of the numeric quantity that we have received, because the bits each mean something in their own right rather than just acting in combination to form a number. You are particularly likely to come across this phenomenon when you are investigating System Exclusive messages, where the instrument manufacturer has coded the state of several on/off switches into one byte (one bit for each switch), for example (see later).

We actually need four bits to form one decimal digit: the smallest decimal digit, 0, is 0000 in binary, and the largest, 9, is 1001 in binary. This means that there are five 4-bit bit patterns left over, ie. 1010, 1011, 1100, 1110 and 1111. These would correspond to the decimal values 10, 11, 12, 13, 14 and 15. So, there is no easy correspondence between binary patterns and decimal digits. Since four bits gives us sixteen possible patterns, we would have a direct relationship between patterns and digit values if we were to count in 16's instead of 10's. Consider the word 'hexadecimal': 'hex' means six and 'decimal' means ten, add 6 + 10 and you get 16! Yep, hexadecimal means base 16 numbers!!

If you have been concentrating you will have noticed that we used two digits for binary and ten digits for decimal (with a symbol for each of the different states we can represent). Would you believe that octal (base 8) uses eight symbols (0, 1, 2, 3, 4, 5, 6 and 7 - note that the numbers 8 and 9 *don't exist* in octal). Using hexadecimal we will need sixteen symbols, of course. We use the familiar 0, 1, 2, ..., 9 for the first ten of the sixteen symbols and we then borrow the first six letters of the alphabet to make up the rest. So, our full 'alphabet of symbols' for hexadecimal is: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F.

If you were counting your money in hexadecimal you might start off with 5 pounds, add 2 pounds, and finish up with 7 pounds (easy stuff first!). If you then added a further 4 pounds you would end up with 7 + 4 = B pounds. Take away 1 pound and you have A pounds (decimal 10). Add 6 pounds and you have 10 (hexadecimal) pounds, where 10 in hexadecimal is 1 x 16 + 0, making 16 decimal pounds.

Since each byte consists of eight bits, it is easy to represent its contents with exactly two hexadecimal digits. It is relatively easy, with a little practice, to remember which bit pattern corresponds to each hexadecimal digit, so just by looking at the hexadecimal digit pair for a byte an experienced user can visualise the full details of the eight bits being considered. Comparing this pattern, bit by bit, with the contents of the instrument's MIDI manual thus becomes a much simpler task.

Let's try some examples. Hexadecimal 00 represents the bit pattern 00000000 (nice and easy). Since F hexadecimal is the 'last' hexadecimal digit it has the bit pattern 1111 - so FF hexadecimal is 11111111 binary, F0 is 11110000, 0F is 00001111. As 5 is binary 0101, then F5 is 11110101. Likewise, B is decimal 11 and binary 1011, so BB is 10111011... and so it goes on!

A nibble (nybble) is half a bite (byte)! Note that many of the MIDI status bytes naturally break into two 4-bit nybbles. In these cases the left nybble tells us what sort of MIDI message we are dealing with and the right nybble tells us the MIDI Channel Number. Let's consider each of these halves in turn.

Considering the left-hand nybble first, we see that there are various restrictions placed upon the values it can hold depending upon whether it forms part of a status byte or a data byte. If we have a *data* byte, the left-most bit must always be off, which means we can only have bit patterns that begin with zero (0000, 0001, 0010, 0111) giving the range of decimal values 0 to 7. This is why the largest data byte is hex 7F (decimal 127). On the other hand, *status* bytes must always have the left-most bit switched on, so they use up the rest of the nybble's available bit patterns (1??? giving 1000, 1001, ..., 1111). So, status bytes run from hex 80 (decimal 128) up to hex FF (decimal 255).

As mentioned above, the right-hand nybble of a status byte often (but not always) contains the MIDI Channel Number. One nybble gives us sixteen possibilities running from hex 0 (decimal 0) through to hex F (decimal 15). The correspondence is obvious: add 1 to the value in the nybble. For example, a nybble of 0 means Channel 1 and a nybble of hex F (decimal 15) is Channel 16.

If we take a complete byte, for example hex 9E, we can now dismember it fairly easily. It is a status byte since the left-hand nybble is greater than or equal to 8 (binary 1000), ie. the left-hand bit is on. If we look up the nybble 9 in the MIDI specification we will find out that we have the status byte of a Note On message. The right-hand nybble is hex E, which we remember (or work out) as being the equivalent of decimal 14, so the MIDI Channel Number is therefore 15 (adding 1 to the nybble value). So, hex 9E tells us we have the start of a Note On message on MIDI Channel 15.

In the **Bit** section above I mentioned the fact that the state of several on/off switches could be stored as bits in a byte. Computer scientists might well then refer to such a byte as a *flags byte*, where each bit is one flag. We already know that a MIDI data byte has only seven bits available for the data, since the left-most bit has to be off (0) in a data byte.

Consider a hypothetical (and very convenient) synthesizer which just happens to have exactly seven on/off switches on its front panel! Assume furthermore that the switches are laid out in a straight line from left-to-right and that they are numbered (also from right-to-left) 6 5 4 3 2 1 0. To record that a switch is 'off' we will set its bit in the flag byte to zero; 'on' will have the bit set to one. So, a byte holding the binary value 00000000 means that all the switches are off, a byte of 01111111 means all the switches are on, and 01110000 means the left-hand three switches (numbered 6, 5 and 4) are on and the right-hand four switches (numbered 3, 2, 1 and 0) are off... and so on.

If we see a hexadecimal value presented on a display for a flag byte, all we do is split the byte into two nybbles (ie. split up the hex digits) and convert each digit into binary. With a bit of practice it is not too difficult to remember the complete set of 4-bit patterns that correspond to the hex digits and, eventually, the conversion to binary becomes second nature. To do the same sort of conversion from decimal to binary (ie. from a three-digit decimal number into binary, in order to extract the state of one switch from its bit), rather than from hex, would generally require a pencil, some paper and an aspirin. If you are keen to try, switch 7 is represented by 128, switch 6 by 64, switch 5 by 32, and so on. A flag's word is the sum of the values corresponding to the switches that are on.

Hopefully the five 'Back To Basics' articles have cleared up a few points for readers who are just getting stuck into MIDI. Reading about what is happening on the *inside* of the technology that affects the tools of your profession or hobby is always likely to be a fruitful pursuit... but there is nothing as good as turning the theory into practice.

Take out and decipher the MIDI section in the back of your equipment manuals. If you have some sequencing software, look up the format of its data files, see what utility programs there are - you may be able to notice and interpret some unexpected bytes in a message. If you want to really get *into* MIDI, you could even try writing some simple programs for *your* home computer to manipulate the messages flowing around your MIDI system. But that's another story (or series of articles)...

The contents of this magazine are re-published here with the kind permission of SOS Publications Ltd.

*Feature
by Jay Chapman*

mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.

If you value this resource, you can support this project - it really helps!

*New issues that have been donated or scanned for us this month.*

*All donations and support are gratefully appreciated - thank you.*