Magazine Archive

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

Talking MIDI (Part 8)

Article from Sound On Sound, August 1986

Final part. Jay Chapman concludes his long-running series on the software aspects of MIDI with a look at the finer points of Active Sensing.

Consultant Jay Chapman brings his explanatory series on MIDI finally to a close with a look at MIDI Timing Clocks, Active Sensing and more.

In this, the last article in our comprehensive introduction to MIDI, we will discuss the System Real Time messages. These bytes are all of the form %11111xxx and so we can have a maximum of eight of them (%xxx going from %000, %001, %111 - don't forget that '%' indicates binary and '&' indicates hexadecimal). Have a quick look at Table 1 which sets them out in all their glory.


Status Byte Description
(&F8) %11111000 Timing Clock
(&F9) %11111001 UNDEFINED
(&FA) %11111010 Start
(&FB) %11111011 Continue
(&FC) %11111100 Stop
(&FD) %11111101 UNDEFINED
(&FE) %11111110 Active Sensing
(&FF) X11111111 Reset

The first thing to notice about this set of messages is that they have no data bytes associated with them ie. they each consist of one Status byte exactly.

When a device receives a System Real Time message it treats it a little differently from all other types of Status byte. As we shall see in a moment, the rules of Running Status apply to Mode and Voice messages and in fact all messages leave the receiver in the latest status received - except for the Real Time Status bytes. When a Real Time Status byte arrives the receiving device takes note of it, does whatever it should for that particular Real Time message, and then immediately reverts back to the status it was in prior to the arrival of the Real Time byte.

Consider the following example:

&90 &3C &40 &C0 &00 ...

We have a Note On (for MIDI channel 1; middle C; medium velocity) followed by a Program Change (for MIDI channel 1; to internal program number 0). After the &90 has arrived, we stay in Note On status until the &C0 arrives when we change into the new status (Program Change) and stay there until another Status byte arrives. If we find that a Real Time byte, say &F8, has been inserted we could have something like:

&90 &3C &40 &F8 ...

In this case, we move into Note On status with the &90 and stay there until the new Status byte, &F8 (MIDI Timing Clock - see below), arrives. Our device notes the &F8 and takes the appropriate action and then does not stay in Timing Clock status. Instead it reverts to Note On status until another new Status byte arrives. If the new byte is Real Time then another one byte temporary change of status will occur.

So, Real Time messages (single bytes) can appear anywhere in the MIDI data stream: interleaved between other MIDI messages or even right in the middle of other messages.

This is a very sensible idea if you think about it: if these messages were held up awaiting entry into the data stream, then they wouldn't be very Real Time by the time they arrived!

However sensible it might be, it certainly gives the software writers pause for thought - we need to have a word or two about Running Status to help explain the problems that can arise.


This section has nothing at all to do with designer label training shoes! You may well remember that Running Status is a good idea because it can save a lot of redundant bytes being transmitted around the MIDI network (or stored in your MIDI sequencer). The basic rule here is that whenever a new Status byte is received - except for Real Time messages - the receiver changes from its current status to the new status and stays there until another Status byte arrives. This happens even if the receiver thinks that it has not yet received all the data bytes that should have followed the original Status byte.

If we are sending information about movement of the pitch-bend wheel, MIDI will possibly be asked to handle a few hundred messages all of which would be three bytes long ie. &En &ll &hh, where &n is the internal MIDI channel number and the data bytes &ll and &hh combine to form the latest position of the pitch wheel (all explained in earlier articles - back issues are available... plug, plug!). So a somewhat stylised series of messages might look like:

&E0 &70 &40 &E0 &71 &41 &E0 &72 &42 &E0 &73 &43 &E0 &74 &44 &E0 &75 &45

With Running Status, even this short series is reduced by five bytes - which is almost a 28% saving! The new series would be:

&E0 &70 &40 *** &71 &41 *** &72 &42 *** &73 &43 *** &74 &44 *** &75 &45

The asterisks have been used to emphasise the gaps where redundant (Status) bytes have been removed - there should be no such gaps in the transmission of course!

In either of these cases the receiver would change into Pitch Wheel Change status when it received the first (or only) &E0 and would expect a pair of data bytes to follow - which they do: &70 &40. Having now dealt with a complete message the receiver awaits further incoming bytes. If the next byte is a Status byte (which it is in the non-Running Status series ie. &E0 again), then the receiver effectively starts over with a completely new message of an apparently new status (since it was just defined by the incoming byte).

If the next byte is not a Status byte (it is &71 in our non-Running Status example), then the receiver assumes that it must be the first of the (one, or two, or more) data bytes for the current message type. With &E0 as the current status, the receiver expects two data bytes, of course, and it will therefore await the second byte of the incoming pair before trying to process the message. Once the second byte (&41) arrives the message is completed, acted upon, and the receiver is again ready for either the next Status byte or the next pair of data bytes. Note that in either case it doesn't matter whether we continue with Running or non-Running Status - provided we always get complete messages, we will be OK.

In the normal usage of MIDI, a majority of messages will be Note Ons followed a little later by the corresponding Note Offs. We can obviously use Running Status to save quite a few bytes here by only sending one Note On Status byte at the start of a chord (followed by key number/velocity data byte pairs for each key pressed down) and one Note Off at the release of the chord (followed by...). In fact, since any Note On message with a velocity data byte of zero actually means Note Off (cunning people these MIDI designers!), we only need to send one Status byte (&9n) which could be followed by thousands of key number/velocity pairs! In one thousand keyboard messages, Running Status would save nine hundred and ninety nine bytes (out of three thousand) - not bad eh?!

Actually, life won't be quite that good because other messages will also need to be sent (eg. sustain pedal pressed, breath controller blown, patch change, etc) from time to time. Each time we change away from Note On status, we will have to include one &9n to get us back again. That's still a big improvement most of the time!

We'll now consider the problems mentioned earlier whilst discussing the very simple but very useful Active Sensing message.


When I mentioned Active Sensing in last month's article I suggested that it was a very good idea and I'll now explain why.

Imagine you've just played the last chord at the climax of a live set and Billy Berserker, your eminent lead guitarist, pogos onto the MIDI lead that connects your master and slave synthesizers. Having thus disconnected your peripheral, Billy leaps in the air signalling the end of the song - everybody stops dead on cue - the crowd go wild! - and your slave synth continues playing E minor 7th - drone, drone, drone... You leap over to the slave to hastily switch it off and the PA produces a corresponding 5000 watt 'thump' to remind you not to panic next time! Billy nuts you affectionately - isn't life wonderful?

So, the question of the moment is: how could Active Sensing have come to your rescue? What you needed, obviously, was for the slave synthesizer to recognise the fact that its master had gone away, was no more, was defunct, kaput! The fact that no Note Off commands were turning up doesn't tell the slave synth that anything is wrong, since it is quite possible that you intended the chord to go on for some time. Active Sensing involves always telling the slave something ("don't panic - your master is here!") at reasonable intervals. If the slave synth doesn't receive a "don't panic" indicator for more than a defined interval of time, it assumes that the master controller has become disconnected and turns off all current Note Ons.

The Active Sensing message just consists of the single Status byte, &FE. If a slave never receives an &FE, it will (well, should) assume that Active Sensing is not being used and will just carry on as normal. However, if a slave receives one &FE it will assume that either it must receive some other message, or it must receive another &FE every 300 milliseconds (ms) maximum. If, after 300ms, nothing has arrived then the slave reacts as described in the last paragraph. In our scenario with the pogoing Mr Berserker Esq, the slave synth would have shut up 300ms (3/10ths of a second) after the MIDI lead was disconnected. Ergo, PA speakers and set climax all saved!


Problem 1. You start your MIDI sequencer recording, flex your fingers, tweak your bow-tie, gather your concentration and play. But in the ten seconds before your fingers actually touched the keyboard, 30 (&FE) bytes were recorded. Result: memory space wasted and about a 1/100th of a second delay introduced on playback! MIDI shifts the bytes out at around 3000 bytes per second, so 30 bytes would take 30/3000ths or 1/100th of a second.

Problem 2. In preparation for a gig, you send a voice parameter dump to the computer. Your synthesizer manual tells you that the dump will be 2000 bytes long so you gather in and store 2000 bytes. At the gig, you send the voice back to the synthesizer and, horror of horrors, it won't load successfully!

In the three seconds between you telling the computer to suck in the data and actually pressing the dump button on the synthesizer, nine Active Sensing bytes were transmitted which became the first nine bytes of the stored dump. Therefore the first 1991 bytes of the dump were all stored 9 places on from where they should have been and the last 9 bytes weren't stored at all!

OK, I think you've got the idea. Provided that our MIDI software (whether you wrote it yourself, or you bought a package for your computer, or it's the dedicated software in the synthesizer) deals correctly with any interleaved Real Time bytes, usually by reacting to them in the approved manner and then filtering them out - so that they don't count as part of the 2000 bytes expected for the dump, for example - then things will be fine.

Note that you should never get an Active Sensing byte interleaved between the two data bytes of a Note On message, since the second byte (the velocity) is received just 1/3000th of a second after the first (the key number) - and since a 1/3000th of a second is less than a 1/3rd of a second, there is no need to send an Active Sensing byte. Some devices send out &FE bytes at much shorter intervals than 1/3rd of a second whether they are needed or not. However, it can make the programmer's life easier!

The other Real Time bytes can, and will, appear anywhere!


The heartbeat of your MIDI system! As with all of the System messages (Common or Real Time), there is no channel specification in a Timing Clock byte so all devices on the MIDI network will see the &F8 and deal with it as they see fit. If a device has no sense of time, eg. a synthesizer that has no built-in sequencing capability, then the byte is simply ignored and the device continues dealing with messages of the current MIDI status which was temporarily interrupted by the &F8.

If the &F8 is received by a sequencer, a drum machine, or a microcomputer that is interested in time information, then the &F8 will cause the device's MIDI clock counter to increment by one and the device will set off whatever needs to happen on the given clock. Every 6 MIDI clocks received will cause the MIDI beat counter to step on one - remember the Song Position Pointer message mentioned in an earlier article which works in units of MIDI beats? So do Start, Continue and Stop - see below.

Typically a sequencer might send several Note On messages to 'play' a chord, a drum machine might 'hit' its bass drum and the microcomputer might re-send the Note Ons of a chord that it had remembered from 12 clocks ago in order to create an echo effect! In each case, the device will probably decrement a timing count associated with the next event as each MIDI clock comes in. When the timing count reaches zero the MIDI message(s) making up the event in question will be sent out.

Each time a new MIDI beat is counted, all the devices must move on by the same amount in the song being played. The MIDI 1.0 Specification therefore defines exactly what a MIDI clock (and hence the passing of one &F8 byte) means: exactly 1/24th of a crotchet. Table 2 shows the relationship between MIDI Timing Clocks and note lengths.


MIDI Clocks Note Length Note Name Midi Beats for:
(dotted note) (triplet note)
96 1/1 semi-breve 144 64
48 1/2 minim 72 32
24 1/4 crotchet 36 16
12 1/8 quaver 18 8
6 1/16 semiquaver 9 4
3 1/32 demi-semiquaver 2
1/64 hemi-demi-semiquaver 1

Note that we can play triplets right down to 1/64th notes (even though we can't actually play 1/64th notes!) but we can't play dotted demi-semiquavers or hemi-demi-semiquavers or double dotted semiquavers. The timing resolution available in any finite system is always going to be limited; many of the more reasonably priced drum machines can only handle 16 events per bar, for example. For rock-n-roll this means that you only have a resolution of 4 beats per crotchet (1/4 note). If the drum machine could handle MIDI Timing Clock bytes it would simply have to count up four &F8s before it moved on to its next 1/16th of a bar event.

Many sequencers increase their timing resolution, and therefore their ability to reproduce accurately a human performance, by the simple expedient of counting (internally) 96 or even 192 clocks or more per crotchet. Upon playing back a MIDI sequence, they use an internal clock running at 4 or 8 times respectively the MIDI clock rate to time the events they send out. Every 4 or 8 counts of their own they send out an &F8 of course!

For most of us the MIDI Timing Clock resolution of 1/24th of a crotchet will prove quite adequate most of the time. However, if you do find that the resolution is not quite enough for jazz, try running the sequencer at double the speed - then you'll have 48 clocks per 1/4 note and, no Mr Berserker, you don't have to play your guitar twice as fast!


Do these terms remind you of the buttons on the front panel of your Roland drum machine? Well, these MIDI messages perform exactly the same function as those buttons!

Up until fairly recently there has been some confusion amongst manufacturers as to whether the actual sending of Timing Clock bytes should be started, continued or stopped when the appropriate button has been pressed. As far as I am aware the right way to do things now is to transmit MIDI clocks continuously and insert the start, continue or stop message as and when the appropriate command is given by the master controller. Some modern devices will cover both possibilities.

'Start' will tell all receiving sequencers and microcomputers to reset their Song Position Pointer to zero and synchronise with the &F8 bytes that follow. 'Stop' says stop the sequence immediately and 'Continue' says do not reset the Song Position Pointer but carry on from the next MIDI beat.


A message to be treated with a great deal of respect and extreme circumspection! This message is intended to restore the whole MIDI network to the state it was in immediately after power up. No MIDI channel specific messages will be of use (in terms of routing) since all devices should power up in Omni On/Poly mode. Patch and channel selections will have to be reselected from scratch and soon. Not a command to be given lightly - in fact, many devices will simply ignore the Reset message, which reduces its usefulness anyway!

The MIDI 1.0 Specification is quite clear on how the Reset message should be used: "...sparingly, preferably under manual control only. In particular, it should not be sent automatically on power up." Otherwise one could envisage a complex MIDI network circulating &FF bytes forever...


Well, there you have it! A series of eight articles which I sincerely hope have given you an understanding of, and an even deeper interest in, the wonderful world of MIDI. Whether you are an expert user of MIDI, or even a dabbler in the black arts of programming your own MIDI software, or simply a musician about to buy your second synthesizer and your first MIDI cable, I hope you have enjoyed Talking MIDI and that the subject is now less mysterious than it perhaps was when Sound On Sound first hit the newsagents!

'Talking MIDI' has merely been the introduction - watch out for follow-up articles that will explore MIDI's potential even further.

Series - "Talking MIDI"

This is the last part in this series. The first article in this series is:

Talking MIDI
(SOS Dec 85)

All parts in this series:

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 (Viewing)

More with this topic

Previous Article in this issue

What's In The Bokse?

Next article in this issue

No Presets Allowed

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

The current copyright owner/s of this content may differ from the originally published copyright notice.
More details on copyright ownership...


Sound On Sound - Aug 1986

Donated & scanned by: Mike Gorman




Talking MIDI

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 (Viewing)

Feature by Jay Chapman

Previous article in this issue:

> What's In The Bokse?

Next article in this issue:

> No Presets Allowed

Help Support The Things You Love

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!

Donations for July 2024
Issues donated this month: 14

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

Funds donated this month: £20.00

All donations and support are gratefully appreciated - thank you.

Magazines Needed - Can You Help?

Do you have any of these magazine issues?

> See all issues we need

If so, and you can donate, lend or scan them to help complete our archive, please get in touch via the Contribute page - thanks!

Please Contribute to mu:zines by supplying magazines, scanning or donating funds. Thanks!

Monetary donations go towards site running costs, and the occasional coffee for me if there's anything left over!

Small Print

Terms of usePrivacy