Skip to content

A New Programming Paradigm

Share this Post:

There is a new programming paradigm that is gaining acceptance in our industry.  As lighting continues to converge with video, we are seeing more and more specialization of equipment and skill sets.  While automated lighting consoles are fantastic for lighting tasks, they are not ideal for programming media servers and other video devices.

Don’t worry, though; there are new lighting consoles in development from several manufacturers that will start to make the differences easier to deal with.  However, they are still inherently lighting consoles and, therefore, will always be a bit more difficult to use for manipulating and playing back video.  The new paradigm (not that new, really) is direct programming on media servers.

A Bit of History

Many devices have allowed some simple playback of video from a lighting console through the years, but nothing really did it correctly until the birth of Catalyst in 2000.  At that first LDI showing, the product had a different name and was barely put together before the doors opened.  (The original name, Vertigo, was already taken by another product, so the name was changed before the product was released.)

Richard Bleasdale and I sat down for breakfast two days before the show started and decided upon the DMX protocol and feature set to be used at the show.  We did not know it, but the basic layout of functions and DMX mappings we created that day would go on to become the standard for all DMX-controlled media servers in our industry.

Lighting designers and programmers were suddenly able to control media playback and make live adjustments to the imagery.  This was revolutionary, and productions around the world jumped on the technology.  Other manufacturers quickly created competition for Catalyst and a new, exciting time was created for lighting designers.  As the abilities of the media servers grew, it became quickly obvious that using DMX (or even Art-Net) for control was very complicated and limiting.  The next big development was the Graphical User Interface built into the media server.

This new system allows programmers to create cues, adjust timing, build sequences and more, directly on the media server.  They can then either eliminate the lighting console or use it to simply trigger the pre-built cues on the server.

Media Servers vs. Consoles

Many lighting programmers have become proficient at programming media servers on their lighting consoles.  In essence, the media server operates just like any moving light, except that it has more parameters.  With a bit of understanding of the server features, it is easy for most programmers to play back and manipulate content from their desk.  However, as shows became more and more complicated, with large pixel mapping, video mapping, curved surfaces and custom masks, programmers have found lighting consoles to be very limiting.

Because turning encoders and selecting layers via fixture numbers quickly became very tedious, media server programmers are increasingly turning to on-board GUI based programming.  Most media servers now include a comprehensive GUI feature set that includes a timeline-based playback methodology.

With a timeline, you can quickly see when a clip start and ends, and also what the other “layers” are doing.  This becomes difficult on a lighting console, as the console does not have all the data about the clips.  The lighting console may have a timeline feature, but if it has no idea of the total length of the video clip, then it cannot show you much information.  A GUI on a media server can also display the total rendered output, or just single-layer information.  Again, it is providing information that is not available to the lighting console.

Once programmed into a timeline or cue-list feature on the server, this information can be triggered via SMPTE, MIDI, DMX or other protocols.  This makes it very easy to implement into a show alongside a lighting controller.  Also, by allowing the media server to be programmed directly, it frees up the lighting programmer to focus solely on the lighting.

GUI Progress

With a timeline programming interface, it becomes easy to build transitions from one piece of content to another and determine when clips start, end, fade, etc.  Because the media server already has all the information about the clips (duration, frame rate, thumbnails), it becomes easy for the interface to display transition points and other pertinent data.  Drag-and-drop selection of content and effects further reduces programming time and allows for instantaneous edits and updates.  On-board GUIs of media servers also provide simple graphical interfaces for warping, collaging, creating custom masks and other complex manipulation features.

When adjusting video to map onto a projection surface, specialized screens or other shapes, most find a custom GUI easiest to work with.  For instance, a simple grid that allows a mouse to click and drag points is much easier than knowing which parameter to grab and turn an encoder wheel.  Furthermore, the results of effects and other settings can be adjusted directly on the GUI instead of manipulating a console and then referring to a monitor or projection surface to “see” the result.  It becomes very similar to working with automated lighting on a visualizer, except that we are now talking about live video manipulation.

Not all media server GUIs are straightforward; in fact, most of them require knowledge of mouse and keyboard shortcuts as well as specifics as to how processes are handled.  However, with a little training (and manual-reading, of course), a programmer can usually be programming pretty quickly.

Blending the Technologies

Lighting console manufacturers want to achieve the ultimate in control and allow total control of media servers and other products.  However, this requires complex data communication and new console interfaces.  Right now, all media server manufacturers have their own protocol and terminology, which makes implementing a “universal” controller very difficult.  There are some in the industry who are working towards creating a standard so that data can be better shared between media servers, consoles and even visualizers.  Unfortunately, like most standards, this will take years to develop and refine.  Until then, it makes total sense for media server developers to continue to work on their own programming methodologies with a stand-alone GUI.  This way they can provide their customers the utmost level of their abilities without worrying about how a lighting console tries to control it.

Some Good Advice

Media server usage is continuing to grow in our industry.  Automated lighting programmers should learn to diversify their knowledge in order to be more marketable.  By learning how to program and operate the GUI of media servers, you will gain abilities that will lead to more jobs.  Most media server companies offer free or reduced cost training that teaches the specifics of their GUI programming.  They will teach you the specifics that are needed to be proficient with their product.  Then you can learn to expand this knowledge to larger systems and apply the knowledge as your programming opportunities grow.