Need Some Live Show Technology History Help Before March 4

this one.png

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.

Need Your Help: Survey for Users of Time Code on Live Shows (Redux)

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! 

Controlling Brightsign Players from Medialon Manager for the Gravesend Inn

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!

Behind the Scenes at Walt Disney World’s Starbright Holidays Drones Show at Disney Springs

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:

2016 Show Networking Best Practices

For my Networks On Shows and In Venues: What Do You Need to Know? panel yesterday at the North American Theatre Engineering Conference (NATEAC), I assembled a panel of experts and together we came up with John, Kevin, and Peter’s Show Networking Best Practices. That panel was Kevin Loewen, Engineering Manager at the Pathway Connectivity office of Acuity Brands Lighting  and Peter Stepniewicz, Principal Show Electronic Engineer, Walt Disney Imagineering. Special thanks also to Kevin Gross, AVA Networks, for giving us feedback on the document.  

We came up with the following list of what we consider current best practices for the use of networks on shows.  This list simply represents the personal opinions of the three of us and not necessarily our employers, etc. 

General Network Architecture

  • View cable/fiber plant as a flexible infrastructure, which potentially can be used for networking, audio/video distribution, DMX 512, or even analog signals.
  • Use wireless only for special use cases where you have no alternative.
  • Select entertainment control protocols that are modern and network-friendly where possible.
  • Hire a qualified contractor for permanent installations, or be sure to read and follow specifications and instructions, and performance-test all network links.
  • Consider venue/show staff knowledge and support sources when designing your system.
  • Choose Static or DHCP address assignment by type of gear that will be used
  • Keep in mind that well designed network/cable infrastructure helps to accommodate future technologies.

Network Hardware

  • 1Gb switches give plenty of bandwidth for most entertainment control applications today and likely into the near future.  10Gb might be useful or needed for current or future special applications (like video) or high capacity backbones.  
  • Avoid consumer-grade switches, and consider using managed switches, since in the context of an entertainment control system, switches are cheap, and some more advanced features (like Internet Group Management Protocol (IGMP)) available in managed switches are increasingly important in modern systems. 
  • Consider using switches made for the entertainment industry, since they are better focused on the needs of our market and our users, have accessible support, and are made to be easy to use; enterprise grade IT equipment can be very confusing to setup.
  • Consider (more expensive) Power over Ethernet (PoE) switches for some specialized applications like IP surveillance cameras and A/V network devices.
  • Consider (more expensive) AVB capable switches if running audio equipment that uses it (Meyer Sound, Biamp).
  • Ensure that Energy-Efficient Ethernet (EEE) can be disabled (or is not implemented) in switches used for audio networks like Dante. 
  • Incorporate monitoring ability.  Computers are cheap these days.
  • Use physically redundant switches or Virtual Local Area Networks (VLAN) to segregate traffic.  VLANs are very easy to configure with modern entertainment-oriented switches.
  • Use small business or enterprise-grade dedicated wireless access points (Cisco, Aruba, Ruckus, etc.) when necessary (and don’t use Wi-Fi for real-time control). Don’t use home grade routers (you don’t likely need the router anyway and if you do, you don’t want a consumer grade router).


  • Comply with the TIA/EIA-568 structured cabling standard.  The B version is more common, but either A or B can be fine if used consistently on a show/venue. 
  • Cat 5e Unshielded Twisted Pair (UTP) is suitable for Gigabit Ethernet and should be fine for most entertainment control applications in North America today and into the near future.
  • Cat 6, 6A or Shielded Twisted Pair (STP) may be required or recommended currently or in the future by some manufacturers for specialized (typically high bandwidth) applications. 
  • Use pre-made patch cables. Companies like Monoprice make cable so cheap that it’s typically not worth crimping your own connectors.
  • Don’t make loops (unless your network equipment specifically supports this sort of topology for redundancy using techniques like Rapid Spanning Tree Protocol (RSTP), or Ethernet Automatic Protection Switching (EAPS)).
  • Keep total Cat 5e segment length under 100m (including patch cables).  Cat 6, depending on the use, can have shorter working lengths.
  • Heavier duty Neutrik Ethercon (and compatible) connectors are available for show purposes.  
  • Heavier duty (and easier to coil) Cat 5e (like Belden DataTuff) is available.
  • For permanent copper installations:
  • Terminate cable runs to a jack in the wall, then use a patch cord for the short run to the equipment. 
  • Minimize the patch cable length since these cables are typically lower performance.
  • Remember that conduit runs are typically specified by others and can often be longer than you think. 80m is a good target length, 90m maximum to accommodate 5m patch cables on each end. 


  • Fiber today is still complicated/expensive to terminate and is best for long runs or high bandwidth applications, or where lightning/extreme EMI immunity is needed.
  • LC Duplex is most common fiber connector in our market; you might also see SFP connectors on networking equipment.
  • Single mode fiber is typically needed for very long distances. 
  • Heavier duty Neutrik opticalCON Duo or Quad ruggedized connectors are available.


  • Physical security is very important in our industry and is your first line of network defense.
  • Keep in mind that few of our protocols have any intrinsic security.
  • Consider not using or restricting access to DHCP servers
  • Use firewalls, start with firewall that is totally closed and open from there
  • Use VPN for remote access
  • Shut down unneeded Wi-Fi (which is very useful for programming, etc.) during the show.
  • Keep your network off the internet.  If you have to put it on the internet, limit and constrain access. A useful approach when this is necessary is to have one machine on the show network and use a highly secure external remote access method to that one machine. Then you are virtually in the show network without exposing the whole thing.

Cool Testing Tools