MIDI Show Control and MIDI note – et cetera...

There are different event-synchronization methods used for show synchronization. Each event is associated with a definitive moment in time, and in terms of audio- or video-tracks, the time scale is the most important tool. The master device can generate the Time Code that will be transmitted to all controllers. It’s also possible to use a different type of synchronization where every device starts in unison, and sustained, constant synchronization is absent. That’s possible thanks to short commands sent from the master device to slave devices. MIDI protocol is ideal for this purpose.

Because the MIDI interface came from the music industry, everything that evolved from it was mostly intended for musical applications. It came out in October 1982. In the beginning, this interface was created in order to connect electronic musical instruments with equipment that sends information about musical notes back and forth.

MIDI language consists simply of control commands and their parameters. MIDI-language commands are called messages. Messages are divided into two basic types: ones that control sound generation, which dictate which notes to play and how loud they should be, and ones that carry out secondary functions, or in other words, ones that control setting adjustments for the tone generator and synchronization (MIDI Time Code or MTC is considered this type).

The first type of messages is called Channel Messages or MIDI note. The second kind are called System Messages. Channel Messages fall into two categories: Channel Voice Messages and Channel Mode Messages. System Messages can be System Real-Time Messages and System Exclusive Messages (SysEx). Only the first type of voice messages (MIDI note) and SysEx messages are used for show synchronization.

Now we’ll talk more about MIDI note and how it’s applied to synchronization. While MIDI note is made up of information about notes, the receiving device doesn’t need to generate sound for a selected note, but can perform other commands instead. Now there are many special programs and consoles in whose settings specific notes can be designated to carry out certain commands.

For example, in a lighting console or audio board, we can set it up that when the note “do” (C) from the first octave is received, a lighting program or video content starts up (each note has its own MIDI number, from 0 to 127). Now when these notes are received through MIDI, the audio and light desks start their programs simultaneously. Moreover, commands of this type are detected instantly and without any delay. Something to know about this method is that with a large number of different MIDI note commands, it can be difficult to keep track of which number corresponds with which action. At some point, MIDI note no longer met theatrical and concert needs, which introduced the desire to create a more specialized control protocol.

In 1989, Andy Meldrum of Vari-Lite suggested creating an open protocol that could connect show systems of different applications and by different manufacturers, and control them with the help of any MIDI controller. At the end of 1989, Charlie Richmond from Richmond Sound Design organized a working group that made up the MMA (MIDI Manufacturers Association) and opened a forum on an electronic message board. The resulting standards project was ratified by the MMA and JMSC (Japanese MIDI Standards Committee). On July 25th, it became “Recommended Practice RP-002,” otherwise known as MIDI Show Control v1.0.

MIDI Show Control messages are categorized as Real-Time Universal System Exclusive.

In MSC specifications, the terms Controller and Controlled Device are used. The device that generates MSC messages, called the Controller, is usually a computer with special software and a MIDI card. The receiving device, lighting desk, media server and other controllers are Controlled Devices.

What’s significant about MSC is that this type of message has certain categories, including a General Category and additional subcategories. There’s also a special ‘All-Types’ category for this type of message which transmits to all controller types. Lighting, sound, machinery, video, projection, special effects and pyrotechnics all have their own category.

Information about which device needs to receive a command is communicated in an MSC command. Each device in a category has its own unique ID that is configured manually in the receiving device’s settings. What does that give us? Now you can send definitive commands to each controlled device that are intended solely for it, and the messages for all remaining devices that have a different category of equipment and ID can just be ignored.

The advantage of MSC over MIDI note is that this protocol’s messages contain concrete action commands and not just a message code that needs an action assigned to it by the end device. There’s a basic group of MSC messages, General Commands, that are valid for all device types. Along with General Commands, there’s an additional Sound Commands group, which is specifically for sound-system synchronization. For general synchronization, we’re only interested in General Commands.

And so, we’ve figured out commands and where to send commands, so now it’s logical to discuss how to apply these commands. In MSC messages, there’s part of a code in which information about a controller’s object is encoded, and which needs to receive a command. A command can contain a cue number, cue list and cue path. The code <Q_number> 00 <Q_list> 00 <Q_path> consists of a scene number to apply the command (CueNumber), what list the scene is on (CueList) and the path where the cue list is (CuePath). There’s an additional option that can contain an always-empty value.

To summarize, you can say this about MSC: First, an MSC message contains information about which type of device a message is intended for, and under which number (Command Format, Device ID). Secondly, an MSC message has a command that needs to be carried out in the receiving device (Command). Thirdly, an MSC message contains information about which object accepts a command in a receiving device (CueNumber, CueList, CuePath).

In contrast, MIDI note has no clear association between commands and actions on a console. In addition, all clients receive MIDI note messages, even if they’re not meant for every client. And finally, with MIDI note messages, it’s not possible to know which object on the console the message is applicable to.

Based on what is outlined above, you could say that MSC is much more functional and has more capabilities than the simple MIDI note. MSC allows you to quickly program commands on the main controller for show synchronization. There’s no need for complicated settings on lighting consoles and other receiving devices. All necessary information is received from the control protocol.

Now you know the basic differences between MSC and MIDI note protocols, their advantages and disadvantages, and how you can use them for show synchronization.

For more information, you could read this article by ETC Technical Support Engineer Hans Hinrichsen, which explains how the Eos lighting-control family receives and transmits MSC commands. And this short article goes over the MSC messages supported by the Eos family.  

*****************************************************************************************************************

Roman Vakulyuk

Award-winning lighting designer Roman Vakulyuk has always been interested in electronics, and he knew as a child what he wanted to do when he grew up. In school, he enjoyed programming and wrote several computer programs. Roman fell in love with music in college and moonlighted as a DJ in clubs. One of the clubs had a professional lighting system, and one night when there was no one at the lighting desk, he decided to give it a try. It was an important moment in his life, because he became infatuated with lighting and worked to become a lighting designer. After immersing himself in the profession, his skills advanced and Roman began to contemplate how to create more dramatic shows. He found out that there was such a thing as synchronization technology that could synchronize all show elements, and he began to research it. Over the years his light shows got better and better, and he began to use synchronization on his own projects. “Now I know so much more than the first time I sat behind a lighting console, but I haven’t stopped learning and progressing, because knowledge is the best path forward,” explains Roman. Currently he works with Global Show Trade (GST), a Moscow-based production company, education center and product showroom. Some of his recent projects include the Bilan 35 concert, the Counter-Strike: Global Offensive cyber tournament opening ceremonies, and the 2015 Circle of Light Festival.