Communication and the expression of ideas is central to the art of lighting. Creating great lighting is a team effort lead by the designer. The language a designer uses to communicate with the team, and specifically the console programmer, is crucial to the process of creating the art. The programmer, in turn, must then train the console in order to orchestrate the lights to ultimately relay the intent of the designer to the audience. There is ample opportunity in this process for misinterpretations to muddy the waters of communication. More recently, and at a furious pace, LEDs and multiple attribute "intelligent" lights have entered the mainstream market and the multitude of options they provide has complicated this process amplifying the opportunity for 'miscue' of intent. The simple act of positioning a fader somewhere on a 0 to 10 scale will no longer suffice.
Not surprisingly, there has been an increasing necessity to simplify the process of lighting control. Unlike the hard and fast rules that have existed for decades, a uniform language for designers and programmers to use when describing light behaviors has been non-existent. Moreover, the method used by the console to communicate to lights has never been standardized. The pioneering manufacturers of automated lighting equipment each implemented different philosophies of control. Historically it has been a challenge for some controllers to turn such lights on, get them in a color and make them move about. In all respects, these consoles were merely outputting numbers, sometimes masqueraded by words to get the job done. But now that intelligent lighting is no longer in its infancy a control system that meets the needs of 21st-century lighting fixtures is a welcome addition to the designers' arsenal. Cognito embraces that challenge and makes programming today's complex lighting systems simple again.
Let's go back to the advent of computer-controlled lighting to examine the issues that plagued communication in the theatre. Before computers entered the theatre, the most popular dimmer controllers were known as piano-boards. These large devices had individual handles for each dimmer and designers would ask operators to move a handle to a position to set the light level. These 'move' instructions were written down as cues and with each one executed in succession you had a show. The advantage of this system (which was only realized fully after the obsolescence of piano-boards) was that each move could be controlled at different rates and multiple moves could be executed simultaneously by different operators.
Computer control first appeared on Broadway in 1975 when Tharon Musser used the Electronics Diversified LS-8 console on A Chorus Line. This new technology allowed for unprecedented repeatability and a huge number of cues executed in record time. As processing power was very limited, decisions had to be made on how to execute these fades. The technology and code development tools of the day dictated that each channel would be recorded in each cue. This greatly simplified the process of playing back a show, or more specifically, jumping from scene to scene during rehearsals. Remember, in the old days of piano-boards, getting to any place at random in the show almost always meant starting from the beginning and executing each cue to ensure accuracy. LS-8 and others could do this with ease. Kliegl quickly followed with the Performance and Strand with Multi-Q and Broadway converted to computer control seemingly overnight. Designers were excited by the apparent new flexibility that these computers offered.
These early computer control systems did not emulate piano-boards, but rather manual preset boards. What designers eventually figured out, given a bit of experience on these consoles, was that they could not achieve the complex cue timing that two or three piano-board operators did in the past. As these preset consoles recorded every channel in every cue, they only moved from state to state. This resulted in robotic or non-organic fades. It was only when Strand introduced the Light Palette that the technological problem that plagued these early consoles was finally addressed on a computer (in North America at least).
People everywhere (and since) have praised Light Palette for marrying designers' desires and computer control by using a common language. Almost every controller that has been accepted on Broadway since has used core concepts introduced by Light Palette. With the advent of intelligent lighting, so many more parameters have entered the equation that the language conventions which have evolved are discordant and technologically inadequate. The language must be overhauled. Conventional lighting control just worked in 2-spaces; Intensity and Time. That is not so with moving light control. There are many, many more parameters. Moving light control and solid state lighting have suffered from the lack of a common language for designers and programmers and manufacturers to use. In its infancy, intelligent lighting control stumbled along just managing to keep up with an evolving technology and never experienced the sort of watershed event that occurred in the industry with the introduction of Light Palette. The problem was compounded by that fact that industry leaders were extremely protective of their intellectual property. There was no sharing of control protocols between lights and controllers. Each manufacturer vigorously protected the methods they used to control their fixtures and automated systems were sole-source. Only recently has the industry evolved to the point where it has accepted that inter-operability is a good thing and there is broad support for ANSI standards such as DMX512 and the inter-operability it enables.
Next: Talking to the Lights with Bit and Bytes