2.3. Standard Specifications

Since data often contain some form of Cue Number designation, a "Standard" specification for transmission of Cue Number and related data provides consistency and saves space in the detailed data descriptions (see 2.5. below).

• Cue Numbers
• Time Code Numbers
• Standard Time Code (types {ff} and {st})
• Drop Frame Notes

Cue Numbers

When a Cue Number is sent as data, the following additional information fields may or may not be included as part of a complete "Cue Number description: Q_list and Q_path. Q-list prescribes in which one of all currently Open Cue Lists the Q_number is to be placed or manipulated. Q_path prescribes from which Open Cue Path within all available cue storage media the Q_number is to be retrieved. The data include these information fields in the following order:

<Q_number> 00 <Q_List> 00 <Q_path> F7

Between each separate field a delimiter byte of the value 00H is placed as shown to indicate the end of the previous field and beginning of the next. It is acceptable to send only:

<Q_number> F7

or

<Q_number> 00 <Qlist> F7

Controlled Devices should be able to accept more than one set of delimiter bytes, including directly before F7H, and even if no Q_number, Q_list or Q_path data are sent. Data are always terminated by F7H.
Q_number, Q_list and Q_path are expressed as ASCII numbers 0-9 (encoded as 30H-39H) with the ASCII decimal point character (2EH) used to delineate subsections. In the example above, cue 235.6 list 36.6 path 59 would be represented by the hex data:

32 33 35 2E 36 00 33 36 2E 36 00 35 39 F7

Decimal points should be separated by at least one digit, but Controlled Devices should accommodate the error of sending two or more decimal points together. Any number of decimal point delineated subsections may be used and any number of digits may be used in each subsection except that the length of the data must not cause the total length of the MIDI Show Control message to exceed 128 bytes.
Controlled Devices which do not support Q_list and (or Q_path) data must detect the 00H byte immediately after the Q_number (or Q_list) data and then discard all data until F7H is detected. Likewise, Controlled Devices which do not support the received number of decimal point delineated subsections, the received number of digits in a subsection or the total number of received characters in any field must handle the data received in a predictable and logical manner.
Controlled Devices which support Q_list and/or Q_path will normally default to the current or base Q_list and Q_path if these fields are not sent with Q_number.
For lighting applications, Q_list optionally defines the Playback or Submaster Controls (0 to 127) with which the cue corresponds.
It is highly recommended that every manufacturer publish a clear and concise description of their equipment's response to the above conditions.

Time Code Numbers

Since data often contain some form of time reference, a "Standard" specification for transmission of time provides consistency and saves space in the data descriptions.
MIDI Show Control time code and user bit specifications are entirely consistent with the formats used by MIDI Time Code and MIDI Cueing and are identical to the Standard Time Code format proposed in MIDI Machine Control 0.05. Some extra flags have been added, but are defined such that if used in the MIDI Time Code/Cueing environment they would always be reset to zero, and so are completely transparent.

Standard Time Code (types {ff} and {st})

This is the "full" form of the Time Code specification, and always contains exactly 5 bytes of data.
Two forms of Time Code subframe data are defined:

• 1) The first (labelled (ff}), contains subframe data exactly as described in the MIDI Cueing specification i.e. fractional frames measured in 1/100 frame units.
  
• 2) The second form (labelled {st}) substitutes time code "status" data in place of subframes. For example, when reading data from tape, it is useful to know whether these are real time code data, or simply time data updated by tachometer pulses during a high speed wind. In this case, as in other cases of "moving" time code, subframe data are practically useless, being difficult both to obtain and to transmit in a timely fashion.

hr mn sc fr (ff/st)

hr = Hours and type: 0 tt hhhhh

tt = time type (bit format):

00 = 24 frame

01 = 25 frame

10 = 30 drop frame

11 = 30 frame

hhhhh = hours (0-23, encoded as 00H-17H)

mn = Minutes: 0 c mmmmmm

c = color frame bit (copied from bit in time code stream):

0 = non color frame

1 = color framed code

mmmmmm = minutes (0-59, encoded as 00H-3BH)

sc = Seconds: 0 k ssssss

k = reserved - must be set to zero

ssssss =seconds (0-59, encoded as 00H-3BH)

fr = Frames, byte 5 ident and sign: 0 g i fffff

g = sign bit:

0 = positive

1 = negative (where signed time code is permitted)

i = final byte identiification bit:

0 = subframes

1 = status

fffff = frames (0-29, encoded as 00H-1DH)

IF final byte bit = subframes (i = 0):

ff = fractional frames: 0 bbbbbbb (0-99, encoded as 00H-63H)

IF final byte bit = status (i = 1):

st = code status bit map: 0 e v d xxxx

e = estimated code flag bit:

0 = normal time code

1 = tach or control track updated code

v = invalid code bit (ignore if e = 1):

0 = valid

1 = invalid (error or not current)

d = video field identification bit:

0 = no field information in this frame

1 = first frame in 4 or 8 field video sequence

xxxx = reserved bits - must be set to 0000

Drop Frame Notes

• 1) When writing time code data, the drop-frame or non-drop-frame status of the data being written may be overridden by the status of the Controlled Device (i.e. the time code from the device itself). For example, if the SET_CLOCK data are loaded with a non-drop-frame number and if the time code on the Controlled Device is drop-frame, then the SET_CLOCK data will simply be interpreted as a drop-frame number, with no attempt being made to perform any mathematical transformations.

• 2) Furthermore, if the above SET CLOCK number had in fact been loaded with a non-existent drop-frame number (e.g. 00:22:00:00), then the next higher valid number would have been used (in this case, 00:22:00:02).

• 3) Calculation of offsets, or simply the mathematical difference between two time codes, can cause confusion when one or both of the numbers is drop-frame. For the purposes of this specification, drop frame numbers should first be converted to non-drop-frame before offset calculations are performed. Results of an offset calculation will then be expressed as non-drop frame quantities.

[Index | Main Paragraph | Previous Paragraph | Next Paragraph ]