UPDATE March 15: I’ll be presenting this timeline at USITT and would like your feedback! Details here.
I’m on sabbatical this semester to work through some ideas I’ve been kicking around in my head for many years about the maturation of live show technology. While of course there is always room for additional innovation, it seems to me that--after a period of fairly rapid and intense development--we now have a large group of mature, well-known production technologies and techniques associated with those technologies. If you see the latest Taylor Swift stadium mega spectacular or a well-funded bar/bat mitzvah, on both shows you can see video walls, truss, chain motors, wireless mics, powered speakers, moving lights, lasers, etc, with all of it controlled by a number of more or less standardized computerized controllers (you might see the same console, in fact, on both events). That is a very different world than the one I graduated into from college in 1985, and also very different from our world early in my career when there were continual disruptive technological developments.
To establish and sequence trends, I’ve been working for too many hours on a fancy timeline which you can view here, (float over any event to see supporting details/products).
Note: Be sure and look at this on a large browser—it may not display properly on a phone.
I can’t possibly document the first ever usage of any particular technology, but instead what I’ve attempted to put on the chart is when a core, modern technology started appearing in the market, and tried to establish some point (somewhat arbitrary) where the technology became “mature”, and found in commonplace usage. There’s no way I know of to establish this exact date, but I want to get the general time where that acceptance point happened.
I’ve only included technologies that were introduced and continue to be used in some way or another; if something was cool but didn’t really succeed it’s not really important here.
I’m including live shows only (theme parks, films etc could be whole other time lines)
I’ve left out costumes/makeup because those areas seem separate (I could be wrong, let me know)
I’ll clean up the formatting when it’s done.
And here’s where I’d like to get your help:
What important technologies am I missing (again, to be included it has to be in widespread use today)? Please include product names dates/references if you have them.
What additional milestone shows (and why they are important) am I missing?
What dates do I have Incorrect and what am I missing? Please include any references you have.
Thanks! Please use the contact form below. I’ll close the timeline on March 4 at 9am.
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!
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!
I stayed after IAAPA in Orlando to see the launch of the GOES-R weather satellite (my camera phone video here) and also caught the opening night of the very cool Starbright Holidays drone show. It only runs through January 8, go see it if you can. Disney has released a behind the scenes video:
And while not the best viewing location, we watched from the drone launch area over in the parking lot by Cirque du Soleil. I didn't have my good camera with me but it's pretty impressive watching these drones take off like a swarm of bees and even more impressive watching them come in for landing. Here's a little camera phone video I shot of the launch area and posted on twitter: