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.
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.
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.
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
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.
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).
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:
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:
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.
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.
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).
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:
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:
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:
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
4.2. RECOMMENDED MINIMUM SETS
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
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