Chapter 6
Timecode and MIDI

Introduction

MIDI (an acronym for Musical Instrument Digital Interface) is a digital control system developed to enable synthesizers, keyboards, sequencers, home computers, drum machines etc., to be interconnected via a standard interface. This standard specifies both the type of connector and data signal protocol and level. At its most basic level MIDI is a means of setting one instrument as slave to another. At its most sophisticated it can be used to create, store and replay complex musical compositions, and can be used to control ancillary equipment such as mixers and effects units. All communication in MIDI is carried in multi-byte serial 'messages'. The system is asynchronous, the data only being transmitted as required. Binary 0 is represented by a current flowing in the link, and binary 1 by no current flow. Each byte is preceded by a start bit and followed by an end bit. The data rate is 31.25 kBaud, ± 1%. This gives a duration of 320 μs for each 10-bit message. In the discussion that follows, the presence of these start and end bits will be assumed, and attention will be concentrated on the message bits. For most message types, the first byte of each message is a status byte, called the 'header', indicating the nature of the following data. As Figure 6.1 shows, these messages are of two broad types: channel and system.

Channel messages

Channel messages are intended for individual items of equipment, which are each identified by a number (the channel number) in the range 0-15. This number requires 4 bits (a nibble) of digital data. Each channel message consists of a header byte, followed by either one or two data bytes. The channel message header byte always commences with a logic 1, followed by a 3-digit message code, and a 4-digit channel number (Figure 6.2). Hence Channel Message Header 110110 1 means:

Figure 6.1 MIDI header bytes can identify (a) Channel Message Codes or (b) System Message Codes.

Figure 6.2 A Channel Message Code comprises a header byte followed by one or more message bytes.

System messages

As Figure 6.1 showed, the system message header byte always starts with a 4-bit system message code, followed by a message type code. Note that the system message header has the first 4 bits set to logic 1. The four least significant bits carry system messages. There are 16 messages (0-15) available, but not all are implemented. Of interest regarding timecode are:

• 1000 Clock signal
• 1010 Start
• 1011 Continue
• 1100 Stop
• Code 0001 implements MIDI timecode, MTC.

The clock signal is used to keep, for example, sequencers accurately synchronized. The clock pulses are transmitted at a rate of 24 per crotchet (quarter note). They do not start and stop instruments, and they contain no time-specific information: they are the digital equivalent of a metronome. ′Start′ messages will cause a sequencer to start its sequence from the beginning, regardless of where it stopped. The ′continue′ message causes a sequencer to start up from where it left off, and the ′stop′ message stops it. A device can be instructed to go to a position by means of a ′song position pointer′, which is calculated by counting the semiquaver (sixteenth note) tempo intervals from the start of a particular sequence.

MIDI synchronizers

Synchronizers used with MIDI systems convert the clock signals into a form suitable for storage on magnetic tape or floppy disc, and reconvert back into MIDI form for replay Simple synchronizers usually just record start, stop and clock signals. They do not generate time information as such, so there is no way of asking a machine to go to a particular time address, though the song position pointer can be used to point to a particular event, such as the start of a song.

More complex synchronizers will allow a degree of synchronization with IEC timecode pre-striped on tape, but they will only read timecode and locate it; they will not generate it. When the tape is replayed, timecode is converted to a MIDI message, usually by a microprocessor within the synchronizer — sometimes via a dedicated port rather than the MIDI interface which simplifies matters. The marriage of timecode with MIDI has been difficult because MIDI clocks and SPPs are tempo based, whereas timecode provides absolute time information. If the tempo of a piece of music is altered after being correlated with timecode, there is obviously going to be a discrepancy.

Some synchronizers will generate a timecode, but this is usually specific to the particular system, and although the manufacturer will probably provide ′backwards compatibility′, there may well be difficulties in interfacing equipment from different manufacturers. Microcomputers equipped with suitable programs and databases are available to convert between timecode and MIDI clock, and to control peripheral devices such as synchronizers. It is now possible to accommodate changes in tempo by updating the database. Synchronizers are available to interface MIDI-controlled machines with traditional timecode-controlled ones. With the aid of the microcomputer, lists can be compiled to manage events and commands, and the data held in these lists fed to individual MIDI peripherals, to be acted on when the time arrives.

MIDI and IEC timecode

MIDI and IEC timecode frequently have to interface in post-production, not just for the marriage of music to pictures, but also for the generation of synthesized effects. To facilitate this, a system of accommodating real time within the MIDI message structure has evolved. It is called ′MIDI timecode′ (MTC), and will be generated either by a synchronizer or by the systems-controlling sequencer. Operational aspects of MTC will be covered at the end of this chapter.

There are two forms of MTC messages, quarter-frame (1EC timecode frame) and full-frame. Each is identified by a header byte. The quarterframe message is preceded by a System Common Header (&F1), the full frame message is preceded by a System Exclusive Header (&F0). Quarterframe messages are sent regularly and carry real-time data. Full-frame messages also carry time data, but this is used to set up a device. A fullframe message may be used to send a machine to a particular location, or it may prepare a machine to act at a particular real-time point.

Quarter-frame messages

The time information in a quarter-frame message is held in a sequence of 8 data bytes, each preceded by a system header byte carrying the system common message code 11110001 (&F1). Four bytes of time data are carried per MIDI frame (hence the term ′quarter-frame′). The code carries time information compatible with that carried by IEC timecode. At 25 MIDI fps the quarter-frame MTC signal will give resolution down to 10 ms, but will take 80 ms to transmit, as the 8 bytes require two frames. This means that only one timecode word in two can be sent. In 24, 30 and 30 drop-frame formats MTC reads only even-numbered frames. In the 25- frame format MTC reads odd-numbered frames for one second and even- numbered frames the next.

The most significant nibble of each quarter-frame data byte has its MSB set to logic 0, the remaining three bits indicating which element of time is being updated. Figure 6.3a illustrates. The time units referred to in the most significant nibble are placed in the last 4 bits of the byte, with the LSB in bit 0 (the last bit). The nibbles are combined in pairs to form a data byte. The values of the time addresses are not coded single denary digits, as is the case with IEC timecode, so the denary value 57 has the digital code 00111001, the first 4 bits being carried by the most significant nibble of the pair, the last 4 by the least significant. With the exception of the ′hours′ byte, all unused leading bits are set to zero. The hours byte always has its MSB (bit 7) set to 0, and bits 5 and 6 carry a code indicating the timecode frame rate. Figure 6.3b illustrates. Table 6.1 gives the time data ident codes; Table 6.2 gives the frame rate codes.

Figure 6.3 Frames, Seconds and Minutes are carried in six of the system message bytes, each preceded by a header byte. The most significant nibble of each message byte identifies the detail of the data (a). Hours information is carried in two message bytes, each preceded by a header byte. The most significant nibble carries details of the frame rate (b).

Table 6.1 MTC quarter-frame time identification codes.

Table 6.2 MTC codes for IEC timecode frame rates.

Quarter-frame codes sent at 25 fps require a data rate of 1600 bits/ second within a total MIDI data rate of 31 250 bits/second. This means that MTC will occupy just 5% of the available data space.

Full-frame messages

There are three types of full-frame message. One carries real-time data, another the binary user group data associated with IEC code, and the last carries set-up messages for peripheral devices. They are sent as required, and take precedence over all other messages, even to the extent of breaking into a message stream. ′Header′ and ′end′ bytes ensure that they can be recognized among the other data. Full-frame MTC messages are carried in consecutive bytes, following a single header byte. The header byte is the system exclusive message code 11110000 (&F0). An end system exclusive message byte terminates the full time message. A minimum of 8 bytes is required to carry the data, making a minimum of 10 data bytes for the complete message. Full time messages can carry machine-specific instructions as well as time data. By their use, machines can be instructed to go to specific time locations and either park or play. If parked, the machine will wait until the corresponding quarter-frame message arrives, then action the instruction.

Real-time message

This carries time information to frame resolution and the frame rate. It does not carry the user bits. Ten bytes are required to carry the whole message. Eight bytes carry time data, preceded and terminated by ′start′ and ′end′ bytes. The full message has the syntax: &F0 &7F <CH> <ID1> <ID2> <HH> <MM> <SS> <FF> &7F. (Information in triangular brackets is variable). The details are covered in Table 6.3.

Table 6.3 Details of real-time message bytes.

Binary group message

This carries the 32 bits of the IEC user groups. Fifteen bytes are required, thirteen of which carry the message. The syntax is: &F0 &7F <CH> <ID1> <ID2> <ID2> <UB1> <UB2> <UB3> <UB4> <UB5> <UB6> <UB7> <UB8> <UB9> &F7. Table 6.4 gives the details.

Byte 14, the identification byte, has the form 0000 00YY. The bits designated YY are the binary group flag bits. They perform the same functions as their counterparts in the EBU/SMPTE code. The assembly of the bits into ISO 646 or 2022 characters is:

User bit data is not sent on a regular basis. It is sent on request, usually from a peripheral device requiring the data in order to execute a command.

Table 6.4 Details of the binary group message bytes.

Set-up message

A set-up message makes it possible for a controlling microcomputer to handle individual devices. The message indicates (among other things) the device the message is intended for, what the machine must do, and when it must do it. One hundred and twenty-eight different messages are possible (remember, the leading bit of a message byte is always zero), but at the time of writing only nineteen messages have been defined. The basic ′set-up′ message comprises a minimum of 13 consecutive bytes, but there is a provision to incorporate additional information, which may include MIDI channel messages. The syntax is: &F0 &7E <CH> <ID1> <ID2> <ID2> <HH> <MM> <SS> <FF> <ff EL> <EM> <AI> &F7. Table 6.5 gives the details. Note that Byte 10 carries fractional frame information to a resolution of 1/100 frame. Not all machines are capable of this degree of resolution.

The additional information bytes carry MIDI channel messages, split into nibbles, with the least significant nibble being sent first. The leading bits in each AI byte are set to zero. The following example illustrates the process. Suppose we wish to incorporate a ′pitch bend′ message to channel 7, with a (change) value of 157. The channel message header byte will be:

Table 6.5 Details of the set-up message bytes.

Leading zeros are added to make a 14-bit number:

00000010011101 This binary number is split into two 7-bit parts:

The channel message will have the form &E7 &1D &01. It will be set in six consecutive additional information bytes with the least significant nibble of each byte being sent first, each AI byte having the first nibble set to zero:

The ′set up indicator′ byte (ID2) can be used to carry 19 possible global messages to peripheral devices. Fourteen of these messages are carried within the byte itself. Table 6.6 gives the functions of the individual ID2 values. The functions are detailed below.

Punch-in (&01) and Punch-out (&02): programmed start and stop of recording. The event number bytes (EL and EM) are used to indicate the track number.

Table 6.6 Full-frame message ID2 byte details.

Delete Punch-in (&03) and Delete Punch-out (&04) erase the punch-in and -out points from the cue list on the peripheral. The time and event number indicated within this message must have the same values as the punch-in and -out.

Event Start (&05) and Event Stop (&06) trigger and stop the execution of an event. The event number indicates the event to be played on the peripheral (e.g. CD track, sequence number of sequencer, lighting cue etc.).

Event Start with Additional Information (&07) and Event Stop with Additional Information (&08) perform the same functions as &05 and &06, and also indicate that additional information is being carried. This additional information takes the form of channel messages. The scope of this additional information will depend on the peripheral involved.

Delete Event Start (&09) and Delete Event Stop (&0A): delete the start and stop points from the event list. The time and event number indicated within this message must have the same values as the event start and stop.

Cue Point (&0B) is a registration mark. It can trigger events without the need to specify an ′out′ point, and enables the positioning of edit registers.

Cue Point with Additional Information (&0C) is identical to message &0B, except that the presence of additional information (held in the relevant bytes) is indicated.

Delete Cue Point (OD) erases the cue point, with or without additional information. The time and event numbers must have the same values as those held in the cue point.

Event Name AI (&0E) indicates that an event name or remarks have been inserted (manually) in the Additional Information byte/s.

A further five special (directed) messages which do not require the primary function of the event number bytes (EL and EM) may be carried in these bytes by putting the indicator byte to &00. Table 6.7 gives the detail of these directed functions.

There is a fundamental difference between MTC & MIDI clock synchronizers, MIDI clock pulses do not carry time information. Separate Start, Stop and Continue messages, in combination with Pointers are used to control sequences. With MTC, the messages carry the complete time information, and slave devices lock to and follow the timecode.

Table 6.7 Full-frame message ID2 byte directed code details

Synchronization between IEC, MTC and MIDI clocks

When a MIDI system is being used in film or video it must process and act on real-time messages, as opposed to those related to tempo. Two approaches are possible: use a synchronizer to convert time addresses to MIDI clock or MTC messages which can then be used by the controlling sequencer; or use a synchronizer with an integral timecode-to-MTC converter. Which one to use will depend on the complexity of the system and the ability of the individual devices to act on the various message types. Figure 6.4 illustrates various possibilities.

Figure 6.4 Possible TC/MIDI combinations. At (a) timecode off tape is converted to MIDI clock messages and song position pointers. The synchronizer could output MTC (b), letting the sequencer generate MIDI clock and SPPs. The TC reader and sequencer can be combined into a single unit, outputting MIDI and MTC. The integral reader/sequencer could interface with a cue list management programme on computer (d), which will control MTC-capable devices.