Five years ago, when I was working on an update of my book, I did a survey about the usage of time code on live shows. Now, five years later, I'm updating the book again so I thought it would be interesting to see what's changed.
I'm interested in the usage of time code on live shows--any kind of show presented live for an audience (I'm excluding broadcast, film production, etc). This includes theatre, concerts, outdoor pageants, fountain shows and spectacles, theme park attractions, etc. etc.
Please take the survey here before 9am NYC time on Thursday, July 20, 2017
I'll publish the results here in late July/early August.
The survey just takes a few minutes, thanks for your time!
This summer I'm working on a ".1" update to my book Show Networks and Control Systems, which was released five years ago. I'm not adding new chapters or anything, but instead updating various technology versions and parameters (adding USB 3 to the USB section, etc), photos, and so on. I'm also reviewing all the text (actually I used text to speech from my phone to read me my book while storm chasing earlier this year) to put things into an updated context, and in the process stumbled across this sentence:
"Lighting control consoles fall into four basic categories (of course, like anything else, the lines between the categories are often blurry): multi-scene preset, sub-master-based rock-and-roll/club consoles, fully computerized systems, and moving-light controllers."
I wrote this a long time ago and last visited the wording five years ago. I mostly work in sound these days, but worked in lighting in the 80's and 90's and still generally track the lighting market; this sentence doesn't make so much sense any more. So to be sure, I posted on Facebook, tagged a few lighting expert friends, and got some great feedback. I asked this question, "...it seems that console worlds are merging. Is that true? Is there a meaningful difference between a "theatre" console today and a "rock and roll" or "moving light" console?" (oh and I checked with all of them to make sure I could share their comments here):
Richard Cadena, author of books on entertainment lighting and electricity, wrote back first:
Yes, you're right. There is now little distinction between consoles. Most high end consoles deal well with moving lights and color changers, and the old school conventional lights on a dimmer are nothing more than a single-parameter light. The old days where there was a moving light programmer and a conventional light programmer are quickly fading to black.
Rob Baxter, production electrician and creator of the Pocket Console added:
This is true...and I think driven as much or more by the advent of multi-parameter LED fixtures than the desire for merging of dmx dimming with mover control. Sometimes, it is still preferable to keep incandescent dimming separate, especially in broadcast or film environments, but with tungsten and SCR dimming going the way of the dodo, this will become less and less the case as old style dimming only consoles die due to lack of sales and less need.
Lighting programmer Paul Sonnleitner added:
I remember a time when even in concert touring, there was a separate lighting console for dimmers, and another for scrollers, when used. But there's no real difference in 2017, and certainly a lot less of a difference than there was in 1985. Your observations are correct.
I think this shift has two different causes. First, with consoles like the WholehogII and the GrandMA came flexibility in what could be stored on a "handle." The days where one needed to store a single look per fader disappeared when one could store a chase, a cuelist, an effect, or a submaster as easily as a look on a fader.
Second, I think in general designers have relinquished a bit of control to the programmer. I have myriad designers who needn't ever see a console screen, or when they do, prefer a magic-sheet style view as opposed to a column of numbers. There's an advantage to looking only at the stage and not a monitor for them, and it's as easy to say "take the backlight up two points" as it is to look at a screen, see the value of the backlight is at fifty percent, for example, and say "take group 14 up to 70 percent."
I'm going to disagree with Rob above. This shift has little to do with LEDs or any other fixture type. I haven't separated dimmers and automated fixtures onto different consoles in about 20 years.
I will venture to say that modern console flexibility allows me to program "rock and roll" and television a lot more theatrically in a cuelist-style scenario while still allowing easy access to other handles on the fly. Even the lighting process has adapted to a single platform.
Rob Baxter responded
I also concur with Paul's thoughts on it as well re: LEDs not driving people to moving consoles, per se, but away from straight up cue-2-cue consoles. It's just too much stuff to control old-style. As for multiple consoles, that actually depends now more on the size and geography of the show than the gear being driven. Some designers or large live layouts lend themselves to additional programmers based on who has what lights and where in the rig, like stage fixtures vs. arena lighting or washes and LEDs vs. framing fixtures. Every show creates it's own control parameters basically, some moreseo than others.
My Citytech colleague John Robinson who also runs lighting for Broadway shows said:
The last show I ran on Broadway that had separate moving light and conventional consoles opened six years ago. Everything since then has been a single console doing everything. There might be a few shows opening with the traditional setup depending on the programmer/designer and the show's needs.
As others have commented, I think the proliferation of multi-parameter channels/fixtures such as LEDs and cheaper moving lights has helped move a lot of the lower-end consoles to add some features that used to only be found in moving light consoles. Something like adding a color picker, pixel mapper, and the need for presets/palettes changed the entire interface.
Access to lower cost touchscreens, USB playback wings and USB facepanels has made PC-based software much more usable and accessible to a wider market. Adding virtual magic sheets and an OSC connection has allowed programmers to create custom console interfaces, expanding what used to be a very rigid limitation by the face panel into some pretty flexible setups. I'm impressed by what some people who have grown up with touchscreens everywhere are coming up with for programming interfaces for mid-range consoles.
There are still some consoles out there that are horrible for busking, so they'll never end up being used for a live show, but those will eventually go away.
Former student and now Local 1 electrician Ben Granucci added:
As the field has seemed to narrow to 2 major players* over the past 5 years (Eos family and GrandMA 2) so have the lines between what they can do. Sure Eos is still the "theater" board and MA is still the "rock & roll" board, but in a lot of cases it has really come down to programmer preference.
Both ecosystems are mature at this point, but neither is showing signs of obsolescence. At least on the Eos side, that means that a lot of the focus is on adding features that were traditionally on the "other" side. There has been a huge focus recently on adding "busking" abilities, something that has traditionally been a weakness of "theater" boards.
(*That isn't to say there aren't plenty of other players, they're all just splitting a relatively small amount of the market these days it seems)
Lighting Designer and fellow Yale Drama School alumnus York Kennedy added:
I think yes. They are converging and the addition of multiple touch screens seems wonderful. Of course I am never the one touching them but the speed at which we can program very complex sequences now is just wonderful. For me the great improvement is that the consoles really have the fixture profiles ready to go and also that a fixtures features can be accessed so quickly now! It's really getting to be quite exciting. I just did a large opera with four acts and only used 12 movable, LED back lights. All that cable and power gone! And now with so much flexibility right at the desk. Another great addition is that the ETC consoles can send the data right to my assistants laptop live, Real time, as we program. Thank you John McKernon and ETC. Truly wonderful.
And from Canada, Mike Glasspool says:
I recently did a lighting design for a small show - theatrical where I used a lot of techniques I typically used in rock and roll and busking shows to build it. Going through and programming the show was much faster and then onsite (1 day prior to show day) I was able to adjust for reality. It was a fairly great experience. I used MagicQ for it. Saved the show a lot of money and meant I could do a lot of the work ahead of time. I literally went from load in to a quick focus then a full run through in the same day.
And Chris Ashworth of Figure 53 reminds me via twitter that many lighting systems today are run from totally software-based solutions:
So it seems my lighting section needs some updating...
p.s. I've been doing this long enough that I'm still kind of impressed that I can post this on FB and get answers within hours--with all the problems of social media it's still pretty amazing.
It's become an annual tradition-since 2009 I've been writing about audio networking from a live sound perspective after recovering from Infocomm. You can see last year's entry here.
This year, it seems, there's not a whole lot to write, since there was more of the same, with some exciting directions for the future which I'll get to in a bit. It was interesting that the AVNU Alliance didn't have a booth as they did in previous years. From what I can see, as I've been detailing here over the years, AVB/TSN has been accepted by some manufacturers in the live sound industry (Meyer, Avid, etc), and it's holding strong there. But the number of Dante products seems to keep expanding, both in the live sound and install markets. Here's the Audinate display on the Infocomm floor:
Audinate kicked off the week with their AV Networking World, which as always features some interesting Dante-based products. Here's a couple favorites, based on Power over Ethernet (my fave). PoE speakers from SoundTube:
Dante PoE headphone amp from RDL:
They are also soon introducing Dante Domain Manager, which looks pretty cool for very large systems.
At the training as part of the event, Audinate rolled out Level 3 of their training program. Level 3 isn't really necessary for most users of Dante systems; it's really aimed at geeks working on large systems. It covers a lot of foundation networking technology, and some very esoteric issues you might encounter in complex systems.
I think it's very smart of Audinate to put forward this training; Levels 1 and 2 (and some new tools available in Dante controller) really changed the way I look at these systems, and increased my confidence when working with Dante networks, where so much of the underlying functionality is invisible.
There were of course some AVB products on the show, but in my world of live sound, I didn't see a whole lot of new development. There was talk of new AVB capable switches, but as of this writing there's still only one that's been certified (Extreme), even though Cisco had an AVB switch on display last year. Looking on that certification list, I do see L'Acoustics has added a couple new AVB-connected amplifier products to their line; unfortunately I missed their booth at the show.
I am excited to see that Meyer is now shipping their Galaxy (Galileo replacement) system (I love the Galileos and use them a lot), which interconnects via AVB:
A friend from Meyer assured me that there would be some solution to get audio in/out from their products to Dante; my uninformed guess is that it will be AES67.
As I wrote back in 2013, AES67, an open standard audio exchange method, may be the key to the success of audio networking for the future and there was a lot of buzz about it at the show. With AES67 in the picture, manufacturers can choose the networking system of their choice, and then just include AES67 interfacing to get audio out (if not control functionality) for other systems. Even with AES67, though, there is still a very important place for Dante, AVB, Ravenna, etc.-all of these systems offer important functions to manufacturers, and in the case of Dante it offers an interface for the users through Dante controller. I still view this unified interface as a key part of the system; it's literally all that most users see of the system.
And as of late last year AES67 is available in Yamaha products, and since we own a lot of Yamaha stuff at the school, I would love to get my hands on some AES67 compatible gear, and see what the process of patching and so on is like. If you have access to some shipping AES67 gear (something like a stage box would be perfect) please get in touch!
In the Gravesend Inn, we have several video playback systems. I originally developed the effects on Dataton Watchout, and this is a great and very powerful technology, but kind of overkill for this straightforward playback application. And the bigger problem over the years is that we would occasionally have problems with an HDMI or display port connector getting pulled out accidentally by a technician, or jostled out by overactive audience members (we mounted the computers near the displays, and the walls of the attraction get slammed), All of this would then cause the display computer to un-recognize the monitor in Windows, and cause it to drop the display, or get into some weird state. This was infrequent but when it did happen it caused a situation that was kind of complicated to reset, with the keyboard on the other side of the scenic wall, the displays sideways, inexperienced student technicians, etc, etc.
So this year, I decided to move all the playback video effects over to Brightsign HD223 players that run on micro SD cards. These amazing little solid state, dedicated players cost about $350 and are made for 24/7 heavy duty digital signage applications; to reset them you just power cycle them. I went back and forth with the sales guy and couldn't really figure out how to control them, but then I ran into Drew Dalzell at IAAPA last year and he told me that they would work; he has used many of them in attractions all over the world. So I took the plunge, ordered them, and worked with my (now former) student Maxime Verdière to get them working over the last semester, and now with summer here got them debugged and tested out.
What had been confusing me before I talked to Drew was that I was trying to find out what the control protocol was. I was thinking of the units as sort of video player. But in fact It's not really a video player, it's a digital signage system, with software custom developed for each application. So there isn't a standard control protocol--you create it as part of the Brightsign program; using a program called Brightauthor, you create a number of "States" which are then linked together: You can then publish this code (with the media) to the box over the network (and the box has a very good network implementation, with default gateway, etc, which we need in this application). We used the "Networked with Local File Networking" mode.
The code above is for the "Dining Chamber" area of the Gravesend Inn. In this case, we need a still frame that looks like a painting, and then we run a video clip when the painting comes to life. For operational purposes we also needed a screen saver mode between shows. In the figure above, you can see the three states. The top one is the "still" frame (which is actually a one second video because we were having problems with smooth transitions from JPG to video files), the bottom left is the main video, and the bottom right is the screen saver state.
Each of the little connector icons is a UDP Input Event, which triggers the next state, such as:
So there really isn't any overall control protocol; there are events that you can use to transition from one state to another. This also means that (as far as I've figured out) you need to duplicate many of these events, because the UDP commands only act from the currently active state. That might be a bit confusing but that's why you see each state in the program above has three events out the bottom (one to trigger each of the other states and another to retrigger itself). This means, for example, you have to enter the same "play" command above three times into Brightauthor, which felt a little weird but seems rock solid in my testing.
Update June 28: Brandon from Brightsign tech support wrote: Just wanted to throw in a quick tip. For "global" events that should apply to multiple states, if you put all the states into a Super State, you can put the events on the Super State and they will be triggered as long as the playback has on a state in the Super State.
Our second setup in the haunted hotel is a bit more complicated, since it has three monitors that play in sync and two separate video files:
Brightsign offers a "brightwall" feature for making video walls, but in this case we already had three 1080p video files done that needed to run in sync, and we decided against using the brightwall and instead having the left screen mastering the other two. To do this, you put all the players in the same "sync domain" and then issue a "link" command from the master player as part of each UDP event:
Then on the slave players, instead of UDP events, you put Syncrhonization events that follow the master:
Instead of UDP strings, the sync events follow the linked out synchronization keyword:
This worked great, but we did notice one weird glitch. Even though the master unit was set to hold its last frame at the end of video clips, the master (not the slaves) would loop the media forever in a jittery, weird way. Brightsign tech support was quick to respond with a solution--adding a "Media End" event on the master which triggered the idle (still) state. Apparently this glitch was due to a tiny discrepancy between the lengths of the master and slave files and the system trying to resolve the difference.
To control all this from Barco/Medialon Manager was pretty straightforward--just creating the UDP commands:
I whipped up a little user screen, which includes a little feedback from the units that I created using the UDP Send commands from each state entry:
Because the fall is so busy, I typically introduce new technologies like this into the Gravesend Inn in the summer when I have time to debug everything and then test the hell out of it. I made a heavy duty test program in Medialon and pounded all the players repeatedly, let them run over a weekend, and they all were rock solid. Once the code was debugged, the only issue I had was when the monitors were put into power save mode overnight, the monitors would power off. Disabling some power off settings in the monitor seems to have fixed that; we'll see for sure this fall!