After a brief absence, Jay Chapman continues the series where he left off two months ago with a further explanation of how Real-Time commands are used in MIDI.

If you glance back to the end of the September issue's article, you will see that we had been looking at MIDI Timing Clock messages. Timing Clocks were the first of the Real-Time messages we had considered, so let's now have a look at the rest of them. In particular, the Active Sensing message, which seems to cause some confusion - not least because it is an optional message. All will be revealed below!

The first three Real-Time messages - Start, Continue and Stop - we can deal with together. Yes, they do correspond exactly to the buttons found on the front of your drum machine or sequencer. If you have a Stop/Continue button rather than two separate buttons, don't worry: when you press the button for the first time a MIDI Stop message will be sent; when you press again a Continue message will be sent, and so on. So, what do these messages do?

Well, you remember the effect of the Time Clock messages? Any of those devices interested in timing and synchronisation that sees a Time Clock message will advance its internal time counter by one clock 'tick' and then look to see if there is any work to do at this new 'time'. A sequencer might play some notes or send a patch change, for example. Note that if the Time Clock is required in any part of a system, MIDI expects it to be ticking away constantly at the tempo set by, and probably controlled by, the device sending out the Clock. Some early MIDI products would actually stop and start the sending of Time Clock messages, which is not what is supposed to happen. To be fair, this area has been somewhat confused in the past - I am fairly confident that what I am telling you now is correct!

WHAT THEY DO

STOP In this context, the MIDI Stop message tells any interested device to stop 'using' the incoming clocks. In other words, they should no longer advance their internal time counter when a Time Clock message arrives. Of course, if they don't move the time counter on then their MIDI 'future' never arrives, so they effectively stop playing! Since for the moment none of the devices can know whether your next command will be Start or Continue, they all leave their time counters exactly where they are.

CONTINUE If the next message you cause to be sent is Continue, then the devices simply start 'using' Time Clock messages again. In other words, nothing at all will happen until the next Time Clock message arrives at a device. At this point it increments its time counter and does any work that is to happen at the new time. It just continues on from the point at which it was stopped.

START If you send a Start message, however, there is a difference. The drum machine, sequencer, or whatever, will start counting Time Clocks again as in the case of the Continue message, but it will first reset its time counter back to zero. In other words, MIDI time has been rewound right back and your sequencer will start playing from the very beginning of the piece. If the MIDI devices you are driving don't understand Song Position Pointer messages (which we will look at in a later article) then the difference between Start and Continue may be all you have in the way of control over where your sequence starts from, ie. from where you last stopped or right from the start.

ACTIVE SENSING

Active Sensing is an optional message. Now there's an interesting idea! After all, if things are optional (like 'go faster stripes' on the Batmobile) we don't actually need them do we? In fact, life is a little more complicated than the word 'optional' would indicate but, yes, you can indeed do without Active Sensing. Let me explain what Active Sensing is used for and then you will be able to see when it is useful and why it's an option that you might like to actually use.

As you already know (because you've read all the earlier 'MIDI Matters' articles), our MIDI messages are ultimately composed of bits - binary digits or 1's and 0's - sent across a MIDI cable forming a circuit between two devices. In common with many such circuits, the two states (1 or 0) are represented by two electrical states of the circuit: either there is a current flowing (0) or there is not (1). There is a possible problem here...

Consider, as an analogy, what happens when somebody (who you can't see) switches on the light in the room you are in. When the bulb lights up, that person has transmitted a '0' to you since current is obviously flowing. Now they switch the light off. You obviously now have a '1' (no current flowing) being transmitted to you. Both of you then agree to synchronise your watches and that your 'master' will transmit and you will receive a new 'bit' at 20 second intervals. Over the next ten minutes the lamp is on, then off, then on for quite a while, then off... as bits are sent to you - all seems to be going well!

Your friend now goes for an extended coffee break, without telling you. Some ten minutes pass by with no sign of the light coming on. You are now in a dilemma: is the light off because you are in the middle of a very long string of '1' bits? Or is the lamp off because there is no message to transmit at the moment? Or has your friend dropped dead? Or has a fuse blown? Or has somebody cut the wires somewhere?

Most of these possibilities are covered by the fact that in asynchronous serial transmission (which is what we are talking about!) an 'idle' line - ie. one that has no bits on it at the moment - would sit in the 'active' state. In our analogy, the light would always be on if no bits were being transmitted. Messages would only be decoded after the light went off for one bit time to tell the receiver that something (a group of bits known as a 'byte') was coming. Also, messages can only be of a certain known length. In this way, if the light goes off and stays off for more than the specified message length, then we are sure that there is a fault in the circuit.

Not all of the problems outlined above have been solved by ensuring that we can tell whether the line is OK in electrical terms. If 'your friend has dropped dead', ie. the master synthesizer has somehow locked up (or 'crashed' in computer terminology), then there will be no more messages coming down the line unless the master synthesizer is reset.

Now, imagine that you are on stage and you have just played the last chord on the master synthesizer and the slave synthesizers are all belting it out with great gusto when the master synth decides to have a fit. You release the chord and nothing stops! The Note Off messages are never generated or sent and the chord drones on and on until the keyboard roadie decides that this isn't one of your better pieces of improvisation and presses the button marked 'keyboard player ejector seat'...

Where does Active Sensing come into this piece of madness? Quite simply, Active Sensing is the message you send when you have nothing else to send. To be more precise, if up to 3/10ths of a second (maximum) has passed without you sending any messages out at all, you send an Active Sensing message. In effect, it is a message that says to any device listening, "hello, I'm still here and able to control you - I just don't have any commands for you at the moment." In this way the slave synthesizer knows everything is right with its world and keeps playing any notes that it had received Note On messages for.

If a slave doesn't receive any messages for more than 3/10ths of a second, it assumes that its master synthesizer is dead. In these dreadful circumstances the slave will shut off all the notes playing without waiting to receive the relevant Note Off messages, since it assumes that the master synthesizer will not be sending them anyway. The net result of this is that the droning chord will stop before the roadie gets anywhere near that eject button!

We are not completely out of trouble yet, however! What happens if your master controller isn't clever enough to transmit Active Sensing (some sequencers don't, for example), or it is clever enough but you have deliberately turned this feature off (I tend to do this on my Yamaha KX88, which is connected to my computer, to stop the latter's input buffers getting filled up with Active Sensing bytes)?

Thankfully, MIDI has one more rule up its sleeve to cope with exactly this problem: if a slave doesn't see any Active Sensing messages at all it assumes that the master controller won't be using the Active Sensing feature. But, if ever just one Active Sensing message is seen, then the slave device expects to see at least an Active Sensing message every 3/10ths of a second, with the consequences as outlined above.

Note that some 'master' devices will send Active Sensing bytes at intervals of much less than 3/10ths of a second, whether the message is really required or not. This makes the realtime programming (slightly) easier and ensures that the message will never, ever arrive too late. The rules say that a MIDI Real-Time message can be sent in the middle of other messages (not just between them but actually interleaved inside them), so no harm can ever be done by transmitting a few extra Active Sensing messages. Provided the software in your sequencer or voice editing packages has been written correctly...

I'll leave you with that comforting thought until next month!