Many live musical performances use lighting and other (non-musical) effects devices to augment the performance. The operation of these devices typically must be cued to the music.

It became desirable to have one device, such as a computer, control all of these various non-musical devices (ie, so that you don't need to operate a separate controller for each device. It's a lot easier to control everything from one place, rather than trying to operate several control panels simultaneously with only 2 hands).

Furthermore, since MIDI sequencers are often used in musical performances, it was desirable to have a sequencer be able to control these non-musical devices. In this way, it would be tremendously easy to cue "lighting and effects events" to "musical events", and one could do so with a familiar musical tool that was being used for musical purposes as well.

For these reasons, a subset of MIDI, using System Exclusive messages, was devised (ie, much like MIDI Sample Dump Standard is a subset of MIDI, also using System Exclusive messages). This set of specific System Exclusive messages, which are used to send non-musical commands to devices such as an electronic lighting system, is called MIDI Show Control. Today, there are numerous non-musical systems which can receive these MIDI commands (via a MIDI jack on the system's main controller), and thereby be remotely controlled by one master controller, or even controlled by a sequencer (for totally automated operation).

In fact, MIDI Show Control is even used to control certain musical tools whose functions aren't normally covered by standard MIDI messages. For example, MIDI Show Control can be used to control a digital tape recorder, accessing various features over MIDI such as setting the punch-in and punch-out times for an overdub.

Device ID

Every subsystem which can respond to Show Control messages should have a unique (ie, individual) ID number. For example, the controller for the lighting system may have an ID of 1. The controller for the dry ice (fog) effects machine may have an ID of 2. Usually, a controller will allow the user to set its individual ID, so that any conflicts between controllers can be resolved. The range of allowable individual ID numbers is 0 to 111 inclusive. By having individual, unique ID numbers, you can use one of these ID numbers in a System Exclusive message, and then the various controllers that are all daisy-chained together via MIDI can determine which controller a particular System Exclusive message is meant for. Of course, even the master controller which is being used to control the entire MIDI Show Control network can have its own, unique ID, in case slaved controllers wish to create and send messages back to the master.

NOTE: It is possible to have two (or more) controllers set to the same individual ID number. What this means is that both controllers always respond to the same Show Control messages with that ID number, and you completely lose individual control over each. There is also no limit as to how many individual ID numbers a given controller can respond to. If desired, a controller can even respond to all 112 individual ID numbers, but this would be akin to a sound module that only operates in Omni mode (ie, not too useful if you have other units daisy-chained). As you'll see below, the Group ID and All-Call Controllers ID make it a moot point to have a controller respond to more than one individual ID number.

In addition, a controller can belong to a group (or several groups if desired). There are 15 possible groups, and therefore 15 group numbers (or IDs). The group numbers are 112 to 126 inclusive. (Note that the group ID numbers do not overlap the allowable individual ID numbers). For example, the ID for the first group is 112. This is useful if you have two or more systems of one type and want to occasionally make them perform the same operation simultaneously. For example, let's assume that you have two separate lighting systems, and therefore two separate lighting controllers. You've set the controller for system 1 to an individual ID of 1. You've set the controller for system 2 to an individual ID of 2. So, you can control system 1 separately from system 2. (ie, To control system 1, you use Show Control messages with an ID of 1. To control system 2, you use Show Control messages with an ID of 2). But, you can also set both controllers to be in group 1 (ie, an ID of 112). So, if desired, you can make both controllers simultaneously respond to one Show Control message by using an ID number of 112 in that message (as opposed to an ID of 1 for controller 1, or an ID of 2 for controller 2). This eliminates having to send the same Show Control message twice, with the individual IDs of each system, when you want 2 devices to perform the same operation simultaneously (and remember that MIDI is a serial transmission, so extra, unnecessary messages negatively impact performance). Usually, a controller will allow the user to set which group ID it is assigned to (if any). The ability to be assigned to a group is optional, and may not be supported in some controllers.

An ID number of 127 (referred to as the "All-Call ID number") is reserved to mean "all devices respond". When a Show Control message with an ID of 127 is sent along the MIDI bus, all controllers should respond to this message if appropriate (ie, if they support the particular command_format and command of that message), regardless of their group or individual ID numbers.

Template

The template for various Show Control messages is (values in hexadecimal):

F0 7F device_ID 02 command_format command [data] F7

The device_ID is one byte, as explained above. This byte should be set to the ID number of the controller(s) which is to receive and carry out this message (ie, not necessarily the ID number of the device which created the message). It could be an individual ID (0 to 111), a group ID (112 to 126), or the All-Call ID (127).

A single SysEx message transmits a single Show Control command (ie, performs one operation). The command_format and command bytes are explained later. If a controller recognizes that a particular message contains its individual ID number, but the particular command_format or command is not supported by the controller, then the controller should ignore the message.

The number of data bytes there are, and what they signify, depends upon the command. Note that MIDI Show Control allows manufacturers the option to use certain command values for their own proprietary purposes, and therefore information about the data bytes for such proprietary commands will have to be obtained from those manufacturers.

Handshaking is not implemented in this protocol. If somehow, a controller misses a message sent to it, then that's a lost message since the sender of that message will never know about the failure. For this reason, it was decided to limit the number of bytes in a Show Control message to 128 bytes maximum. Furthermore, devices should attempt to transmit a whole Show Control message as quickly as possible (ie, don't put unneeded delays inbetween data bytes being sent), and close a message with the terminating F7 immediately after the data has been transmitted. Most devices have at least a 256 byte MIDI input buffer, so this should eliminate failures in a responsive system.

command_format

The command_format byte can be any value from 0 to 127 inclusive. The value 0 is reserved for any possible future extensions to MIDI Show Control, and should not be used otherwise.

I consider "command_format" to be an ambiguous description of what this byte signifies. This byte actually signifies what type of device a particular Show Control message is intended for. For example, is this message for a stage light? Is this message for a movie projector? Is this message for a dry ice machine? Each one of these types of devices has a different value for command_format. Therefore, I think that "device_type" is a much more accurate description of what this byte really signifies. So whenever you see the term "command_format", mentally replace it with "device_type" for a clearer understanding of the purpose of this byte in a Show Control message.

MIDI Show Control defines several "General" categories of devices. For example, there is a category for "Lighting" devices. There is another category for "Video" devices. There is another category for "Projection" devices. There are other General categories too.

MIDI Show Control also defines more "Specific" sub-categories for each of these "General" categories. For example, there are several specific types of "Lighting" devices; "Strobes", "Lasers", "Moving Lights", among others. There are several specific types of "Video" devices; "Tape Machines", "Monitors", "Switchers", among others. There are several types of "Projection" devices too.

So, depending upon the value of command_format in a particular message, you can determine what type of device that message is intended for. For example, a message could refer to the General catagory of "Lighting" devices, in which case all lighting devices would want to respond to that message. Of course, Video and Projection devices would not want to respond to that message. A message could even be more specific. For example, maybe a message's command_format refers to "Strobe" lights. In this case, not only would Video and Projection devices not want to respond to this message, neither would other types of Lighting devices such as "Lasers" and "Moving Lights" want to respond to this message.

The values for the General categories are chosen such that the least significant nibble (ie, bits 0 to 3 inclusive) are always 0. (The one exception to this is the "Lighting" category which is 0x01 -- due to the fact that 0x00 is reserved for future extensions). For example, the command_format value for the general "Video" catagory is 0x30. The command_format value for the general "Projection" catagory is 0x40.

MIDI Show Control defines a command_format value of 127 to refer to "all types of devices". This is useful for system wide "broadcasts" of identical commands to devices of the same device_ID (or to all devices when used with device_ID = 127). For example, use of this All-types command_format along with the All-call device_ID can allow a complete system to be RESET with a single message.

Many controllers will find it sufficient to respond to only one command_format (besides All-types). In other words, all of their functions fall under that one command_format (ie, will be controllable via messages with that one command_format).

More complex controllers may choose to respond to more than one command_format if they are in control of more than one type of system (for example, a controller that controls both a strobe light as well as a video monitor). In other words, the controllers' functions don't fall under just one simple catagory (ie, the messages of one command_format don't cover all of the functions performed by the controller, so additional command_formats are needed).

A master controller should be able to create and send messages with any command_format, otherwise its usefulness will obviously be limited.

Here is a list of the defined values (in hex) of command_format, and the type of device each value represents:

 Hex     command_format
 ------------------------------------------------------
 00      reserved for extensions

 01      Lighting          (General Category)
 02      Moving Lights
 03      Colour Changers
 04      Strobes
 05      Lasers
 06      Chasers

 10      Sound             (General Category)
 11      Music
 12      CD Players
 13      EPROM Playback
 14      Audio Tape Machines
 15      Intercoms
 16      Amplifiers
 17      Audio Effects Devices
 18      Equalisers

 20      Machinery         (General Category)
 21      Rigging
 22      Flys
 23      Lifts
 24      Turntables
 25      Trusses
 26      Robots
 27      Animation
 28      Floats
 29      Breakaways
 2A      Barges

 30      Video              (General Category)
 31      Video Tape Machines
 32      Video Cassette Machines
 33      Video Disc Players
 34      Video Switchers
 35      Video Effects
 36      Video Character Generators
 37      Video Still Stores
 38      Video Monitors

 40      Projection         (General Category)
 41      Film Projectors
 42      Slide Projectors
 43      Video Projectors
 44      Dissolvers
 45      Shutter Controls

 50      Process Control     (General Category)
 51      Hydraulic Oil
 52      H20
 53      CO2
 54      Compressed Air
 55      Natural Gas
 56      Fog
 57      Smoke
 58      Cracked Haze

 60      Pyro                 (General Category)
 61      Fireworks
 62      Explosions
 63      Flame
 64      Smoke pots

 7F      All-types

command

The command byte can be any value from 0 to 127 inclusive. The value 0 is reserved for any possible future extensions to MIDI Show Control, and should not be used otherwise.

The command byte may be followed by one or more data bytes, up to a total message length of 128 bytes.

Defined MIDI Show Control commands will be listed and described later. If this set doesn't encompass the functionality that you need, you can take values for the command byte which are not defined, and use them to create your own set of proprietary Show Control messages. So how can be future, defined Show Control messages be added to the specification without breaking everyone's proprietary use of those currently undefined values for the command byte? Well, that's why the values of 0 for the command and command_format bytes are reserved for future extensions. Those reserved values, rather than currently undefined values, will be used to extend the defined set.

Future extensions

command_format value 0 and command value 0 are reserved for extensions to Show Control's set of defined messages. (These extensions can only be sanctioned by the MMA. Do not create your own extensions using these values of 0 for command_format and command. There are other, undefined command_format and command values that you can use to create additional, proprietary Show Control messages).

There are two formats that this can take. In both formats, the value for command_format is 0, which is a tipoff to any device that it is receiving an extension to the basic set of defined Show Control messages. The first format (referred to as "First Extension Level") has a command value of 1. The second format (Second Extension Level) has command value of 0, followed by another byte with a value of 1.

00 01 1st extension level
00 00 01 2nd extension level

All devices should currently ignore any Show Control message with a 0 for command_format (since no extensions have yet been defined).

Data bytes

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 signify 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. 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 (Section 5). 3.1. 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: 00 00 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: F7 or 00 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. 3.2. 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. 3.2.1. 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:

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.

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 00-17hex)
          mn = Minutes: 0 c mmmmmm
               c = colour frame bit (copied from bit in time code
                   stream):
                    0 = non colour frame
                    1 = colour framed code
               mmmmmm = minutes (0-59, encoded as 00-3Bhex)
          sc = Seconds: 0 k ssssss
               k = reserved - must be set to zero
               ssssss = seconds (0-59, encoded as 00-3Bhex)
          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 identification bit:
                    0 = subframes
                    1 = status
               fffff = frames (0-29, encoded as 00-1Dhex)
     If final byte bit = subframes (i = 0):
          ff = fractional frames:  0 bbbbbbb (0-99, encoded as   
               00-63hex)
     If final byte bit = status (i = 1):
          st = code status: 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

  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.

    To convert from drop-frame to non-drop-frame, subtract the number of frames that have been "dropped" since the reference point 00:00:00:00. For example, to convert the drop-frame number 00:22:00:02 to non-drop-frame, subtract 40 frames, giving 00:21:58:22. The number 40 is produced by the fact that 2 frames were "dropped" at each of the minute marks 01 through 09, 11 through 19, 21 and 22.

    (Some manufacturers will prefer to store all internal time codes as a simple quantity of frames from reference point 00:00:00:00. This reduces calculation complexity, but does require that conversions are performed at all input or output stages).

4.2. RECOMMENDED MINIMUM SETS

MIDI Show Control does not specify an absolute minimum set of commands and data which must be implemented in each device responding to a given command_format.

However, in order to ease the burden of interfacing between Controllers and Controlled Devices from different manufacturers, four RECOMMENDED MINIMUM SETS of commands and data have been created. Once a Controlled Device is specified to conform to a particular Recommended Minimum Set, then the task of designing a Controller which will successfully operate that device is considerably simplified.

The currently defined Recommended Minimum Sets are:

  1. Simple Controlled Device; no time code; basic data only

  2. No time code; full data capability

  3. Full time code; full data capability

Assignment of any particular command or data to a Recommended Minimum Set may be found in the far right hand column of the Index List.

Recommended Minimum Sets are in no way intended to restrict the scope of operations supported by any device. They are offered only in the spirit of a "lowest common denominator". 4.3. GENERAL COMMANDS

The following commands are basic to the current implementation of Memory Lighting systems and probably apply to all dedicated theatrical show control systems in a general sense. Although it is not required that Controlled Devices incorporate all of these commands, it is highly recommended:

                                               Number
                                               of data  Recomm'd
 Hex command                                   bytes    Min Sets
 ---------------------------------------------------------------
 00  reserved for extensions
 01  GO                                        variable 123
 02  STOP                                      variable 123
 03  RESUME                                    variable 123
 04  TIMED_GO                                  variable -23
 05  LOAD                                      variable -23
 06  SET                                       4 or 9   -23
 07  FIRE                                      1        -23
 08  ALL_OFF                                   0        -23
 09  RESTORE                                   0        -23
 0A  RESET                                     0        -23
 0B  GO_OFF                                    variable -23 
4.4. SOUND COMMANDS

The following commands, in addition to the above, are basic to the current implementation of Computer Controlled Sound Memory Programming Systems and are widely used by Show Control Systems in more comprehensive applications. It is recommended that Controllers support the transmission of these commands:

                                               Number
                                               of data  Recomm'd
 Hex command                                   bytes    Min Sets
 ---------------------------------------------------------------
 10  GO/JAM_CLOCK                              variable --3
 11  STANDBY_+                                 variable -23
 12  STANDBY_-                                 variable -23
 13  SEQUENCE_+                                variable -23
 14  SEQUENCE_-                                variable -23
 15  START_CLOCK                               variable --3
 16  STOP_CLOCK                                variable --3
 17  ZERO_CLOCK                                variable --3
 18  SET_CLOCK                                 variable --3
 19  MTC_CHASE_ON                              variable --3
 1A  MTC_CHASE_OFF                             variable --3
 1B  OPEN_CUE_LIST                             variable -23
 1C  CLOSE_CUE_LIST                            variable -23
 1D  OPEN_CUE_PATH                             variable -23
 1E  CLOSE_CUE_PATH                            variable -23

Detailed descriptions of each Command (and its data bytes)

    00   Reserved for future extensions.

    01   GO

         Starts a transition or fade to a cue. Transition time
         is determined by the cue in the Controlled Device. If
         no Cue Number is specified, the next cue in numerical
         sequence GOes. If a Cue Number is specified, that cue
         GOes.
         Transitions "run" until complete.
         If the Controller wishes to define the transition time,
         TIMED_GO should be sent.

         In Controlled Devices with multiple Cue Lists, if no Cue
         Number is Specified, the next cues in numerical order
         and numbered identically and which are in Open Cue Lists
         GO. If Q_number is sent without Q_list, all cues with a
         number identical to Q_number and which are in
         Open Cue Lists GO.

          01              GO
                optional; required if Q_list is sent 
          00              delimiter
                  optional; required if Q_path is sent
          00              delimiter
                  optional


    02   STOP

         Halts currently running transition(s). If no Cue Number
         is specified, all running transitions STOP. If a Cue
         Number is specified, only that single, specific
         transition STOPs, leaving all others unchanged.

          02              STOP
                optional; required if Q_list is sent
          00              delimiter
                  optional; required if Q_path is sent
          00              delimiter
                  optional


    03   RESUME

          Causes STOPped transition(s) to continue running. If no
          Cue Number is specified, all STOPped transitions
          RESUME. If a Cue Number is specified, only that
          transition RESUMEs, leaving all others unchanged.

           03             RESUME
                optional; required if Q_list is sent
           00             delimiter
                  optional; required if Q_path is sent
           00             delimiter
                  optional


    04   TIMED_GO

         Starts a timed transition or fade to a cue.  If no Cue
         Number is specified, the next cue in numerical sequence
         GOes. If a Cue Number is specified, that cue GOes.
         Transitions "run" until complete.

         Time is Standard Time Specification with subframes (type
         {ff}), providing anything from "instant" to 24 hour
         transitions. If a Controlled Device does not support
         TIMED_GO it should GO instead, ignoring the time data
         but processing Cue Number data normally. If the
         transition time desired is the preexisting default cue
         time, GO should be sent instead of TIMED_GO.

         Rules for Controlled Devices with multiple Cue Lists are
         the same as for GO, above.

          04              TIMED_GO
          hr mn sc fr ff  Standard Time Specification
                optional; required if Q_list is sent 
          00              delimiter
                  optional; required if Q_path is sent
          00              delimiter
                  optional


    05   LOAD

         Places a cue into a standby position. Cue Number must
         be specified. LOAD is useful when the cue desired takes
         a finite time to access. LOAD is sent in advance so
         that the cue will GO instantly.

         In Controlled Devices with multiple Cue Lists,
         if Q_number is sent without Q_list, all cues with a
         number identical to Q_number and which are in
         Open Cue Lists LOAD to standby.

          05              LOAD
                required
          00              delimiter
                  optional; required if Q_path is sent
          00              delimiter
                  optional


    06   SET

         Defines the value of a Generic Control. The Generic
         Control and its value are each specified by a 14 bit
         number. A Controlled Device may treat virtually any of
         its variables, attributes, rates, levels, modes,
         functions, effects, subs, channels, switches, etc. as
         Generic Controls which may be sent values via SET. 
         Optionally, the time it takes the Generic Control to
         achieve its value may be sent.

         Time is Standard Time Specification with subframes (type
         {ff}), providing anything from "instant" to 24 hour
         transitions. If a Controlled Device does not support
         times in SET, it should ignore time data.

           Standard Generic Control Numbers for Lighting:

              0-127      Sub masters
              128-129    Masters of the first playback
              130-131    Masters of the second playback
               ...
               etc.
               ...
              190-191    Masters of the 32nd playback
              192-223    Speed controllers for the 32 playbacks
              224-255    Chase sequence masters
              256-287    Chase sequence speed masters
              510        Grand Master for all channels
              511        General speed controller for all fades
              512-1023   Individual channel levels

          06              SET
          cc cc           Generic Control Number, LSB first
          vv vv           Generic Control Value, LSB first
          hr mn sc fr ff  Standard Time Specification, optional

 
    07   FIRE

         Triggers a preprogrammed keyboard Macro. The Macro is
         defined by a 7 bit number. The Macros themselves are
         either programmed at the Controlled Device, or loaded
         via MIDI file dump facilities using the ASCII Cue Data
         format or any method applicable to the Controlled
         Device.

          07              FIRE
          mm              Macro Number


    08   ALL_OFF

         Independently turns all functions and outputs off
         without changing the control settings. Operating status
         prior to ALL_OFF may be reestablished by RESTORE.

          08              ALL_OFF


    09   RESTORE

         Reestablishes operating status to exactly as it was
         prior to ALL_OFF.

          09              RESTORE


    0A   RESET

         Terminates all running cues, setting all timed functions
         to an initialized state equivalent to a newly powered-up
         condition and loads the first cue of each applicable cue
         list into the appropriate standby positions. In other
         words, RESET stops the show without arbitrarily changing
         any control values and loads the top of the show to
         standby.

         It should be decided by the manufacturer of the
         Controlled Device whether or not RESET should
         automatically open all CLOSEd_CUE_LISTs and
         CLOSEd_CUE_PATHs and this decision should be stated
         clearly in the device's MIDI Implementation
         documentation.

          0A              RESET


    0B   GO_OFF 

         Starts a transition or fade of a cue to the off state.
         Transition time is determined by the cue in the 
         Controlled Device. 

         If no Cue Number is specified, the current cue GOes OFF.
         If a Cue Number is specified, that cue GOes OFF.

         In Controlled Devices with multiple Cue Lists, if no Cue
         Number is Specified, all currently active cues in Open
         Cue Lists GO OFF. If Q_number is sent without Q_list,
         all cues with a number identical to Q_number and which
         are in Open Cue Lists GO OFF.

         For compatibility with Controlled Devices which do not
         automatically replace an existing cue with a new cue
         upon receipt of the GO command, Controllers should
         optionally prompt the programmer to simultaneously
         create a GO_OFF command.

          0B              GO_OFF
                optional; required if Q_list is sent
          00              delimiter
                  optional; required if Q_path is sent
          00              delimiter
                  optional 
 

    10   GO/JAM_CLOCK

         Starts a transition or fade to a cue simultaneous with
         forcing the clock time to the 'Go Time' if the cue is
         an 'Auto Follow' cue. Transition time is determined by
         the cue in the Controlled Device.

         If no Cue Number is specified, the next cue in numerical
         sequence GOes and the clock of the appropriate Cue List
         JAMs to that cue's time. If the next cue in numerical
         sequence is a 'Manual' cue (i.e. if it has not been
         stored with a particular 'Go Time,' making it an
         'Auto Follow' cue), the GO/JAM_CLOCK command is ignored.

         If a Cue Number is specified, that cue Gop and the clock
         of the appropriate Cue List JAMs to the cue's time
         unless the cue is 'Manual' in which case no change
         occurs.

         Rules for Controlled Devices with multiple Cue Lists are
         the same as for GO, above.

         
          10              GO/JAM_CLOCK
                optional; required if Q_list is sent 
          00              delimiter
                  optional; required if Q_path is sent
          00              delimiter
                  optional


    11   STANDBY_+

         Places into standby position the next cue in numerical
         order after the cue currently in standby.

         If Q_list is not sent, the Open Cue List containing the
         next cue in numerical order is used. If more than one
         Open Cue List have cues with an identical number then
         those cues will move to their respective standby
         positions.

         If Q_list is sent in Standard Cue Number Form, only
         the next cue in the Cue List specified moves to the
         standby position.

          11              STANDBY_+
                  optional


    12   STANDBY_-

         Places into standby position the previous cue in
         numerical order prior to the cue currently in standby.  

         If Q_list is not sent, the Open Cue List containing the
         previous cue in numerical order is used. If more than
         one Open Cue List have cues with an identical number
         then those cues will move to their respective standby
         positions.
 
         If Q_list is sent in Standard Form, only the previous
         cue in the Cue List specified moves to the standby
         position.

          12              STANDBY_-
                  optional


    13   SEQUENCE_+

         Places into standby position the next parent cue in
         numerical sequence after the cue currently in standby.

         'Parent' refers to the integer value of the cue's
         number prior to the first decimal point (the "most
         significant number"). For example, if cue 29.324.98.7
         was in standby and the cues following were 29.325, 29.4,
         29.7, 29.9.876, 36.7, 36.7.832, 36.8, 37., and 37.1,
         then cue 36.7 would be loaded to standby by SEQUENCE_+.

         If Q_list is not sent, the Open Cue List containing the
         next cue in parental sequence is used. If more than one
         Open Cue List have cues with a completely identical
         number then those cues will move to their respective
         standby positions.

         If Q_list is sent in Standard Form, only the next
         parent cue in the Cue List specified moves to the
         standby position.

          13              SEQUENCE_+
                  optional


    14   SEQUENCE_-

         Places into standby position the lowest numbered parent
         cue in the previous numerical sequence prior to the cue
         currently in standby.

         'Parent' refers to the integer value of the cue's
         number prior to the first decimal point (the "most
         significant number"). For example, if cue 37.4.72.18.5
         was in standby and the cues preceding were 29.325, 29.4,
         29.7, 29.9.876, 36.7, 36.7.832, 36.8, 37., and 37.1,
         then cue 36.7 would be loaded to standby by SEQUENCE_-.

         If Q_list is not sent, the Open Cue List containing the
         previous parental sequence is used. If more than one
         Open Cue List have cues with identical lowest numbered
         parent cues in previous parental sequence then those
         cues will move to their respective standby positions.

         If Q_list is sent in Standard Form, only the first
         parent cue in the previous sequence of the Cue List
         specified moves to the standby position.

          14              SEQUENCE_-
                  optional


    15   START_CLOCK

         Starts the 'Auto Follow' clock timer. If the clock is
         already running, no change occurs. The clock continues
         counting from the time value which it contained while it
         was Stopped.

         If Q_list is not sent, the clocks in all Open Cue Lists
         Start simultaneously.

         If Q_list is sent in Standard Form, only the clock in
         that Cue List Starts.
         
          15              START_CLOCK
                  optional


    16   STOP_CLOCK

         Stops the 'Auto Follow' clock timer. If the clock is
         already stopped, no change occurs. While the clock is
         stopped, it retains the time value which it contained
         at the instant it received the STOP command.

         If Q_list is not sent, the clocks in all Open Cue Lists
         Stop simultaneously.

         If Q_list is sent in Standard Form, only the clock in
         that Cue List Stops.
         
          16              STOP_CLOCK
                  optional


    17   ZERO_CLOCK

         Sets the 'Auto Follow' clock timer to a value of
         00:00:00:00.00, whether or not it is running. If the
         clock is already stopped and Zeroed, no change occurs. 
         ZERO_CLOCK does not affect the clock's running status.

         If Q_list is not sent, the clocks in all Open Cue Lists
         Zero simultaneously.

         If Q_list is sent in Standard Form, only the clock in
         that Cue List Zeros.
         
          17              ZERO_CLOCK
                  optional


    18   SET_CLOCK

         Sets the 'Auto Follow' clock timer to a value equal to
         the Standard Time sent, whether or not it is running.
         SET_CLOCK does not affect the clock's running status.

         If Q_list is not sent, the clocks in all Open Cue Lists
         Set simultaneously.

         If Q_list is sent in Standard Form, only the clock in
         that Cue List Sets.
         
          18              SET_CLOCK
          hr mn sc fr ff  Standard Time Specification
                  optional


    19  MTC_CHASE_ON

         Causes the 'Auto Follow' clock timer to continuously
         contain a value equal to incoming MIDI Time Code. If no
         MTC is being received when this command is received, the
         clock remains in its current running or stopped status
         until MTC is received, at which time the clock
         continuously exhibits the same time as MTC. If MTC
         becomes discontinuous, the clock continues to display
         the last valid MTC message value received.

         If Q_list is not sent, the clocks in all Open Cue Lists
         Chase simultaneously.

         If Q_list is sent in Standard Form, only the clock in
         that Cue List Chases.
         
          19              MTC_CHASE_ON
                  optional


    1A  MTC_CHASE_OFF

         Causes the 'Auto Follow' clock timer to cease Chasing
         incoming MIDI Time Code. When MTC_CHASE_OFF is
         received, the clock returns to running or stopped status
         according to its operating status at the instant
         MTC_CHASE_ON was received.


         MTC_CHASE_OFF does not change the clock time value; i.e.
         if the clock is stopped, it retains the last valid MTC
         message value received (or simply the most recent time
         in the clock register); if the clock is running, it
         continues to count from the most recent time in its
         register.

         If Q_list is not sent, the clocks in all Open Cue Lists
         stop Chasing simultaneously.

         If Q_list is sent in Standard Form, only the clock in
         that Cue List stops Chasing.
         
          1A              MTC_CHASE_OFF
                  optional


    1B   OPEN_CUE_LIST

         Makes a Cue List available to all other commands and
         includes any cues it may contain in the current show.

         When OPEN_CUE_LIST is received, the specified Cue List
         becomes active and cues in it can be accessed by normal
         show requirements. Q_list in Standard Form must be
         sent.

         If the specified Cue List is already Open or if it
         does not exist, no change occurs.

          1B              OPEN_CUE_LIST
                  required
 

    1C   CLOSE_CUE_LIST

         Makes a Cue List unavailable to all other commands and
         excludes any cues it may contain from the current show.

         When CLOSE_CUE_LIST is received, the specified Cue List
         becomes inactive and cues in it cannot be accessed by
         normal show requirements, but the status of the cues in
         the list does not change. Q_list in Standard Form must
         be sent.

         If the specified Cue List is already Closed or if it
         does not exist, no change occurs.

          1C              CLOSE_CUE_LIST
                  required


    1D   OPEN_CUE_PATH

         Makes a Cue Path available to all other MIDI Show
         Control commands and to all normal show cue path access
         requirements as well.

         When OPEN_CUE_PATH is received, the specified Cue Path
         becomes active and cues in it can be accessed by the
         Controlled Device. Q_path in Standard Form must be
         sent.

         If the specified Cue Path is already Open or if it
         does not exist, no change occurs.

          1D              OPEN_CUE_PATH
                  required
 

    1E   CLOSE_CUE_PATH

         Makes a Cue Path unavailable to all other MIDI Show
         Control commands and to all normal show cue path access
         requirements as well.

         When CLOSE_CUE_PATH is received, the specified Cue Path
         becomes inactive and cues in it cannot be accessed by
         the Controlled Device. Q_path in Standard Form must be
         sent.

         If the specified Cue Path is already Closed or if it
         does not exist, no change occurs.

          1E              CLOSE_CUE_PATH
                  required