Talking MIDI (Part 8)
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.
Table 1. SYSTEM REAL TIME MESSAGES
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.
Table 2. MIDI TIMING CLOCKS versus NOTE LENGTHS
|MIDI Clocks||Note Length||Note Name||Midi Beats for:|
|(dotted note)||(triplet note)|
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.
Feature by Jay Chapman
Previous article in this issue:
Next article in this issue:
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!