Universal System Exclusive Format
MIDI Show Control uses a single Universal Real Time System Exclusive ID number (sub-lD #1 = 02H) for all Show commands (transmissions from Controller to Controlled Device).
In this version of Show Control, no command responses (from Controlled Device to Controller) are specified or required in order to optimize bandwidth requirements, system response time and system reliability in the event of communication difficulties with one or more Controlled Device. The guiding philosophy behind live performance control is that, as much as possible, failures ot individual Controlled Devices should not impair communications with other Controlled Devices. This concept has been a part of MIDI design from the beginning and MIDI Show Control continues to use an "open-loop" design in order that standard MIDI practices may continue to be successfully utilized in applications using all types of standard Channel and System messages. However, a "closed-loop" version of Show Control has been discussed and may be created in the future.
In this document, all transmitted characters are represented in hex unless otherwise noted. The initials "msc" will be used to denote the new MIDI Show Control sub-lD #1 (= 02H). The format of a Show Control message is as follows:
Note that:
Commands are most often addressed to one device at a time. For example, to command two lighting consoles to GO, transmit:
Every device must be able to respond to both an individual and the "all-call" (7FH) ID. The group addressing mode is optional. A device may respond to one or more individual ID and one or more group ID. Both <device_lD> and <command0_format> of a message must match the device_lD and command_format of a controlled device before the message is recognized.
If two separate controlled devices responding to the same command_format are set to respond to the same device_lD then only one message need be sent for both to respond.<BR>
The "all-call" device_lD (7FH) is used for system wide "broadcasts" of identical commands to devices of the same command_format (or to all devices when used with <command_format = all-types>; see Index List-Command_Formats, below).
Before fully interpreting the <device_lD> byte, parsing routines will need to look at <msc> and <command_format>, both of which follow <device_lD>, in order to first determine that the Sysex contains Show Control commands in the appropriate format.<BR>
A typical system will consist of at least one Controller attached to one or more Controlled Devices. It is possible for the same machine to be both a Controlled Device and a Controller at the same time. In this case, the machine may act as a translator, interpreter or converter of Show Control commands. According to its programmed instructions, the receipt of one type of command may result in the transmission of similar or different commands.
It is also a possibility that multiple Controller outputs could be merged and distributed to one or more Controlled Devices.
Optionally, Controlled Devices may be able to transmit (from a MIDI Out connector) MIDI Show Control commands of the type required by themselves to produce a desired result. In this condition, the Controlled Device will be transmitting a valid MIDI Show Control command but may not necessarily be doing so as a Controller.
This is useful when the Controller has the ability (through MIDI In) to capture valid MIDI Show Control messages in order to conveniently create and edit the database of messages needed for the performances being controlled. In this case, the Controlled Device will be transmitting to the Controller, but only for the purposes of capturing messages to store and retransmit during performance.
Another application allowed by the transmission of Show Control commands by Controlled Devices is the slaving of multiple Devices of similar type. For example, if a dedicated lighting console transmits a Show Control command to "GO" when its GO button is pressed, then any other dedicated lighting console that obeys MIDI Show Control commands will also GO if it receives MIDI from the first console. In this way, many Controlled Devices may be controlled by another Controlled Device acting as the Controller. Interconnection would follow the same pattern as the normal Controller to Controlled Device arrangement.
Command_formats A command_format is a message byte from a Controller to a Controlled Device which identifies the format of the following Command byte. Each command_format has a format code between 01H and 7FH, and must be tollowed by a valid command byte. (Command_format 00H is reserved for extensions, and not all codes are currently defined.)
Commands A command is a message byte from a Controller to a Controlled Device. Each command has a command code between 01H and 7FH, and may be followed by one or more data bytes, up to a total message length of 128 bytes (Command 00H is reserved for extensions, and not all codes are currently defined).
Extension Sets
Command_Format 00H and Command 00H are reserved for two extension sets:
Data Length
The only restriction to the number of data bytes sent is that the total number of message bytes must not be more than 128. The actual data format of the transmitted message will be defined by the manufacturer of the Controlled Device. This means that the Controller (or the programmer of the Controller) must know the exact data format of the Controlled Device. This information will be manufacturer and equipment specific, so it is important that every manufacturer publish a thorough and unambiguous Sysex Implementation document.
Because this specification is intended to accommodate the needs of an extremely wide variety of equipment and industry needs, from very low cost light boards to the most complex audio/video multimedia extravaganzas, the data formats used in simpler systems will be considerably shorter and less complex than in comprehensive equipment. Data are transmitted in the order of most generic information first, with null character delimiters between each group of data bytes in order to signity the sending of progressively less generic data. For instance, simple Controlled Devices may look only at the basic data and discard the rest.
As an example, a complex Controlled Device may be able to process cue numbers with a large number of decimal point delineated subsections i.e. "235.32.7.8.654". If a Controller transmits this cue number to a simple Controlled Device that can only process numbers in the form "xxx.x", then the simple Device can either ignore these data or else respond to them in a predictable manner, such as processing cue number "235.3."
As a further example, cue number data may be transmitted calling up cue 235.3 then followed by a delimiter and data specifying cue list 36.6 and followed by a further delimiter specifying cue path 59. If the Device supports multiple cue lists but not multiple cue paths, it would process cue 235.3 in cue list 36.6 (or 36) and ignore the cue path data, simply using the current or default cue path.
Looking at the situation in the opposite manner, if simple cue number data were transmitted to a Device capable of processing all cue data, it would respond by processing that cue number in the current or default cue list using the current or default cue path.
[Index | Main Paragraph | Previous Paragraph | Next Paragraph ]