Welcome back to this series that intends to introduce the basic concepts of lighting music. We’ve gone over the major kinds of lights, developing a plot, creating references, and cue placement. Now it’s time to talk about synchronizing your lighting with the music playback. We’ll go over the major kinds of show control and what their advantages and disadvantages are.
Synching Feeling
Show control for music spans three major delivery methods (MIDI, Linear Time Code, Network) and three major protocols (SMPTE, MIDI Show Control, MIDI Notes). You will need to combine one delivery method with one protocol to get anything to happen, though you certainly could choose to combine more for special projects. They all have advantages and disadvantages, so let’s talk about them and why you might choose one over the other. Please note that the delivery methods and protocols don’t always have a clear delineation between them, so forgive some overlap in descriptions.
MIDI
MIDI was published in 1983 as a method for synchronizing electronic musical instruments. I’m not sure where or how, but the lighting industry grabbed the protocol and ran with it- even having a new extension specifically for synchronization between consoles published in 1990.
Advantages:
- Solid for decades.
- Parts are easily available if you have even a modest music store around and they tend to be pretty cheap.
- Multiple methods: You can send notes, MSC (MIDI Show Control) and even send time code over MIDI.
Disadvantages:
- 7 bit protocol, which means that it only has 128 steps between 0 and full.
- No confirmation- the message is sent and the receiver never sends a “Got it” message.
Linear Time Code
This protocol started with the movie industry in 1967. It’s an actual sound representation of an 80 bit protocol that simply conveys hours, minutes, seconds and frames per second. Since it is essentially an audio representation of time, it includes not trigger functions. The receiver (in our case, the lighting console) needs to be able to be programmed to take actions based off of the time. Please not the time isn’t actual and relevant to the time of day. It’s just a convenient way to synchronize many events.
Advantages:
- Very powerful and simple
- Allows control of timing to stay on the lighting console- therefor, the lighting person is always programming their console to make adjustments.
Disadvantages:
- LTC can be expensive ($600-1000) to add to your console if it’s not already included at purchase.
- According to Best Practice- you must roll a second or two before you can expect triggers to be taken cleanly. In my experience, I was able to reliably get things working with only half a second of pre-roll, but your results may vary depending on your console and setup.
Network
Kind of a broad term here, but it’s a broad category. Network allows versions of MSC, MIDI and Linear Time Code to be passed through it, but also has other things as User Datagram Protocol (UDP) and Open Sound Control (OSC). UDP (also known as Un Delivered Protocol in moments of rage) allows many show control events to be controlled, but has struggled with reliability. OSC is amazing, so let’s talk more about it.
Open Sound Control started its life as a high resolution replacement for MIDI. But the design and implementation of it was so well done that it quickly became much, much more. Currently, you can send timecode, send MSC messages, or send actual commands to your console (depends on manufacturer implementation). It’s easy to program and customize, reliable and powerful.
Advantages:
- Network based
- Ultra high resolution
- Incredibly diverse range of controls and options offered
Disadvantages:
- You need to understand basic networking
Protocols
SMPTE
SMPTE simply announces the time and devices that are compliant allow you to synchronize nearly anything in your console to it. You can do SMPTE over audio (LTC), MIDI, or network. It’s incredibly straightforward as a protocol. As long as you understand how your console works with timecode, you’re good to go. When using SMPTE over LTC- it’s incredibly easy to sync your playback source. If the music starts in the middle of the song and the console is in the first cue, it will snap to the appropriate cue when the first “known” time marker is passed. When you try the same thing with MIDI, it’s less successful when using Qlab because of the limits of Group Cues (last time I used the program at least), but great if you are using a sequencer like Protools, Logic, Reaper, etc. I haven’t yet done SMPTE on network, so I don’t know how well scrubbing a timeline works over different applications.
Advantages:
- Easy to synch with your music playback
- Excellent travel distance
- Incredibly reliable
Disadvantages:
- Depending on your console and if you are using LTC, MIDI or network, setting up could cost between $0-1000.
MIDI Show Control (MSC)
MSC was published in 1991. Though simple- it’s surprisingly strong. It simply relays commands. If one console presses Go onto Cue 5, and the second console has a Cue 5, both will roll into the cue at the same time. If you need to pause the Cue mid-roll, they will both pause. If you need to back up a Cue, they both back up. You can control multiple cue lists with MSC as well. You cannot have timecode over MSC. So for music playback and show control, you typically need to add these commands either to a timeline (a sequencer) or as a list of countdown commands that synch with the music (Qlab). This means the commands for your console are on a sound computer, which can make adjusting your cues challenging.
Advantages:
- Very simple and well integrated
- Incredibly stable
- Cost effective
Disadvantages:
- No timecode
- If having the “sound computer” trigger your light cues, it’s difficult for you to edit the timing when you are at your lighting console.
- When troubleshooting, it can be very hard to know what is going wrong.
MIDI Notes
This last category isn’t used as often as the other two, but is really helpful when you need to trigger things WHILE using MSC or SMPTE since it adds another option. It’s also useful when you have a device that doesn’t have MSC or SMPTE integrated, so you need another method of sending commands (I’m looking at you, Propresenter). It’s usually the longest way to do something since you will have to configure both the sender and the receiver for anything to work. If it’s not obvious why this is, it’s because a MIDI note by default is configured to trigger a note on an instrument and that’s it. Using it to trigger an event that isn’t that musical note is a custom configuration on both sides.
All things considered, it’s still a useful option. The only weird thing about it is the amount of memorization and documentation you will need to do. If you have several triggers, it’s easy to forget if C#0 is trigger the lightning or the thunder for example. The protocol is a bit limited because a MIDI note message tells the receiver what note was triggered at what velocity (how hard the note was hit). So it’s an on/off switch with volume control. If you are using tactile triggers, it’s great to program in a velocity conditional such as “when the note is hit harder than 100 of 0-127, take the commands”. That way, the actor or whoever picking up the tactile trigger won’t accidentally trigger the event.
Wrapup
Hopefully this overview of show control is useful to help you choose which method to use and why. Show control is something I see a lot of programmers avoid. This is sad because it’s super cool and allows you to do some amazing things, but also because the people who can do it well get paid more. I have several tutorials on my website about show control and how to configure Eos and Qlab and such to work together. Warning: you must experiment with these protocols BEFORE you have to make them function at work. There are many things to learn to get reliable show control and you don’t want to set yourself up to fail. Practice and experimenting is vital to success.
Anyone have a cool show control story? My first tutorial was about the time I timecode a musical for a small theater. I had a great time and learned a tremendous amount. Tell me about what you’ve done in the comments.
***
Mark LaPierre is a programmer in film and television based out of Albuquerque. He grew up in live entertainment and has been a designer/programmer for musicals, concert dance, live music, circus and corporate. Mark is a proud member of IATSE and an ETC Eos trainer. If you enjoy his content, please consider commenting on his posts on the website to appease the Algorithm.