MIDI Show Control - Roma Robot

MIDI SHOW CONTROL

THE FIRST SMART SYNC PROTOCOL

At a certain point, a simple MIDI sound protocol was not enough for theater and concert needs, and this eventually led to creation of a more specialized control protocol.

In 1989, Andy Meldrum, an employee of Vari-Lite, proposed the development of an open protocol that would allow the connection of show systems for various purposes into a single network, so that they could be controlled using MIDI commands from the main controller.

By the end of 1989, Charlie Richmond had organized a working group as part of the MMA (MIDI Manufactures Association) and created a common forum on the USITT (The United States Institute for Theater Technology) electronic board. The resulting draft standard was approved by the MMA and JMSC (Japanese MIDI Standard Committee) and on July 25, 1991, it was turned into “Recommended Practice RP-002,” otherwise known as MIDI Show Control version 1.0.

MSC

MIDI Show Control messages relate to Universal Real Time System Exclusive type of MIDI events.

The MSC specification uses the terminology Controller and Controlled Device. The device that generates MSC messages, called the Controller, is usually a computer with specialized software and a MIDI card. Receiving devices, lighting consoles, media servers and other executing controllers are the Controlled Device.

A feature of MSC is that messages of this format have certain categories. They are divided into main (General Category) and additional subcategories. There is also a special category All-types. Messages of this type are broadcast to all types of controllers. The general categories include light, sound, machinery, video, projection, special effects and pyrotechnics.

For all of this, information about the device that should receive the command is transmitted in the MSC message.

Each device within one category has its own ID. It is set manually in the settings of the receiving controller. Within the same category, the IDs of all devices must be different. The unique ID of each device can be in the range 1 - 111.

What gives us the use of ID? Now it is possible to send commands specifically for each receiving controller, and all other controllers that have a different equipment category and ID will simply ignore these messages.

Also in the ideology of MSC, there is such a thing as Group ID and Broadcast ID.

Each device can have a unique ID but at the same time, it can be subscribed to group messages. For this, special group IDs from 112 to 126 are reserved in MSC.

There can be 15 independent groups in total. If we need to receive group message that clients subscribed, the server just needs to send an MSC message to one of the group IDs.

There is also one reserved ID equal to 127 for broadcast commands. MSC commands sent to this ID will be received by all clients.

An additional advantage of MSC over MIDI note is that the messages of this protocol contain specific commands for the action, compared with MIDI note where we have just the note message code to which the action on the execution controller needs to be attached. There is a main group of MSC messages, General Commands, that are applicable for all types of devices. In addition to General Commands, there is an additional group, Sound Commands, specifically for sound synchronization systems. For general synchronization, we are only interested in commands like General Command.

Now that it’s clear where to send command messages and also what commands we can send. Let's talk about what these commands are applicable to.

MSC messages contain a part of code about the object in the controller to which the command should be applied.

<Q_number> <Q_list> <Q_path>

This code consists of the number of the Cue to which to apply the command (CueNumber), on which list this Cue (CueList) is, and the path to where the list of Cues is (CuePath).

The last value remains from the time when the lighting consoles saved their shows on floppy disks and the remote control could reproduce light scenes, both from the internal memory and from the external memory. CuePath indicate where the final goal of the message was. Now this MSC parameter is used to specify an additional option that depends on each controlling system.

Not all messages from all MSC commands carry the object to which the command should be applied, mainly global commands, such as ALL OFF or RESET.

Summarizing all the features of MSC, we can say the following:

First, the MSC message contains information about which type of device and under which device number the message is intended.

Command Format, Device ID

Second, the MSC message has a command that must be executed on the receiving device - Command

Third, in the MSC message there is information on which object in the receiving device to apply the command -

Q Number, Q List, Q Path.

These capabilities extend the MSC functionality many times over with simple audio MIDI messages. This allows you to quickly program commands on the main controller to synchronize the show. There is no need for complicated settings on lighting consoles and other receiving devices. They receive all the necessary information according to the control protocol.

Now back to the story. After the creation of MSC v1.0, it became so popular that a new, improved version of MSC v1.1 was later developed. The main difference was that this version of MSC now implies feedback between the server and the client. The application of the new version of the protocol was aimed at dangerous systems, such as scene mechanics.

In the new ideology of the protocol, the client, before receiving data from the server, must send a response to the server about the possibility of performing the action, and after receiving the command, it must also inform the server whether the command was successful or not. Such a command confirmation system was designed to improve the security management of complex systems. But besides the obvious advantages of feedback from the server, there was one drawback, it consisted in the speed of synchronization. The server could not send a new command until a response was received about the execution of the previous command. Unfortunately, the complicated version of MSC v1.1 has not yet been widely used in the show industry. But MSC v1.0 was very popular for a long time, until new protocols based on modern data transfer technologies replaced it.

And this is OSC, Open Sound(System) Control that was developed to replace the outdated MIDI protocol. It,s a new sync protocol, with new features and possibilities. Subscribe and so you won’t miss this article.