pathway cognito2 User manual

1
Natural Language Control
as used in
TM
This essay explains the core technology used in Cognito's internal 'fade engine'
that makes DMX512 and runs the lights and the end devices at the bits and bytes
level. Reading this and understanding Natural Language Control is not necessary
to operate the console, but it will give you an appreciation of how lighting control
has advanced over the years. Using today's advanced lighting systems has never
been easier because of Natural Language Control.1
!
BACKGROUND!.............................................................................................................................................................................!2!
TALKING!TO!THE!LIGHTS!WITH!BITS!AND!BYTES!...............................................................................................................!4!
TALKING!TO!THE!LIGHTS!WITH!NATURAL!LANGUAGE!CONTROL!....................................................................................!4!
PAN!AND!TILT!EXAMPLE!..........................................................................................................................................................!6!
ZOOM!EXAMPLE!......................................................................................................................................................................!10!
SHUTTER!CONTROL!EXAMPLE!.............................................................................................................................................!11!
GOBO!CONTROL!......................................................................................................................................................................!14!
CONDITIONAL!ABSTRACT!ATTRIBUTES!.............................................................................................................................!18!
ATTRIBUTE!SUBSTITUTIONS!................................................................................................................................................!21!
PHANTOM!ABSTRACT!ATTRIBUTES!....................................................................................................................................!24!
COLOR!SPACES!........................................................................................................................................................................!27!
CONCLUSION!............................................................................................................................................................................!30!
© 2015
1Much of this document was originally published in 2005 by Horizon Control in a white paper
called The Abstract Control Model. Horizon was purchased by Acuity Brands Lighting in 2011 and
the entire team joined Pathway Connectivity when it too was acquired by Acuity.

2
Background
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.

Natural Language Control as used in Cognito2
3
Computer control first appeared on Broadway in 1975 when Tharon Musser used
the Electronics Diversified LS-8 console on A Chorus Line.2This 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
2For a detailed description of the LS-8 and other early computerized lighting control systems see
Robert Bell’s book Let There Be Light
ISBN 9781904031246

4
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.
Talking to the Lights with Bits and Bytes
The earliest forms of computer control, though digital at their core, output an
analog signal, typically between 0 and 10 volts. Many architectural luminaires are
still controlled this way. The control signal set the lights' output from zero to full
intensity. Inside the controller, these numbers were generally stored using 8-bit
words, giving 256 steps of resolution. With the advent of moving light systems,
the resolution was doubled to 16-bit, providing 65536 steps of resolution.
Computers then calculated fades that produced a one-to-one relationship
between the 65,000 steps directly to motors that moved the light from, say, pan-
stop to pan-stop. This concept persisted for years and, given a specific controller
tied to a specific lighting system, pre-programmed shows were reproduced
faithfully night after night.
The downfall of this method of control is that these numbers ([0-10], [0-255] or
[0-65535]) mean very little in the real world. They are actually only significant
when used with very specific equipment. When applied to other equipment, these
numbers mean very little at all, and in fact are often meaningless.
Talking to the Lights with Natural Language Control
Natural Language Control's objective is to provide an intuitive programming
experience and a versatile control system that when played back can actually
provide the operator information about the system it is controlling.
Natural Language Control does this by porting the control to an 'abstract' layer.
This has a number of benefits:
1. The 'handles' you use to control LEDs and moving lights are more inline with what you
would do to manipulate conventional lighting.

Natural Language Control as used in Cognito2
5
2. The numbers and 'words' you use to build cues will actually mean something. You will
have an idea of what you can do with the lights and what is on stage by reading the
display.
3. If you have mixed equipment, the methodology you use to communicate is consistent
regardless of the protocols defined by the equipment manufacturers. The attribute
controls are laid out the same for every and any light.
4. Building a set of looks with one group of lights in your rig can be copied to another
groups, regardless of what type of lights they are.
5. The cues you have in your show file can be played back with any equipment allowing
you to swap out gear at the last minute if need be.
One of the key things in Point #2 above that bears repeating is that Natural
Language Control uses numbers and 'words' to control lighting. One might claim
that has been done for years with the use of 'named' palettes. For example,
moving lights desks can use labeled position palettes to build cues and the cue
displays these 'words' to make it easier to read. Don't lose sight of the fact that
palettes, like "Down Stage Center", are just placeholders for a combination of
values between 0 and 65535. The words themselves do not mean anything to the
desk. They are just displayed on the screen for convenience. In contrast, with
Natural Language Control, the words do mean very specific things within the cue
structure. Some of the words used include:
•3200 Kelvin
•15 degrees of pan
•rotate counter clockwise at 6 RPM
•strobe at 9 hertz
•reset the fixture's driver
During regular operation, these 'words' need to be converted into 'values' that
DMX512 lighting fixtures can use. The trick with Natural Language Control is that
this conversion is done each and every time a light is selected, a Memory is
recalled or GO is pressed to start a cue (and not before). That means that the
protocol, the mode, the model or the manufacturer of the lighting fixture can be
changed at any time. Moreover, each and every light, regardless of who makes it,
appears similar to the user, giving a more consistent experience when
programming the console.
Apart from the benefits described above, this method of controlling lights is not
restricted to traditional linear channels mapped to attributes on the light. A few
examples below will demonstrate the intuitive nature of describing lights'
attributes as opposed to traditional convoluted methods that sometimes group
completely unrelated behaviors on the same control channel.

6
Pan and Tilt Example
The Home position for pan and tilt on most DMX lights is 50:50 (or 32767:32767).
This positions the light such that you will have maximum movement in each
direction before encountering a pan-stop or tilt-stop. For a light that has a total
pan range of 360 degrees, with the control channel set to half, you are sitting at
180 degrees. Taking the control channel to full will move the light 180 off axis
towards a stop. So, to summarize, a value of 50% means "go to Home", and a
value of 100% means "go to the pan-stop 180 degrees from Home". Figuring out
that 90 degrees is half way in between those two values is easy. That would be
75%. And a 45 degree pan from Home is, again, half way between those two
values or about 63%. Now it begins to get a little too complex for the programmer
to calculate quickly.
To add to the complication, imagine you have another light in the rig that has a
total pan range of 540 degrees.
Now the numbers you just figured out for the first light mean nothing to this one.
Worse yet, if you grab them both and pan them in tandem, you would get
completely differing results:

Natural Language Control as used in Cognito2
7
The angles of pan are completely different. The beams of light are not even close
to parallel. You can see how this can be very frustrating if you have a mixed rig.
With Natural Language Control, the Pan attribute is represented in real-world
units of degrees. Therefore, when you talk to the light, you tell it to pan so many
degrees:
Forty-five degrees is forty-five degrees. This makes controlling a rig that is made
up of different types of lights easy to communicate with and easy to understand.
Since Natural Language Control doesn't figure out DMX values until the very last
second, it can also alter the way in which the conversion is done at run-time,

8
producing new and exciting methods of transition during the fade from cue to
cue. Various attributes, such as position and color lend themselves very nicely to
working in different ways. Color Space is described in detail below, but let's
examine how we can move from one place to another on stage given two stored
end places.
Moving lights achieve movement by physically moving the source with two
motors housed within a yoke. This Pan/Tilt relationship equates to a polar
coordinate system using azimuth and elevation. When you pan more than you tilt
the light will move in an arc:
We have become used to this characteristic movement of intelligent lights. Very
good moving lights that move extremely smoothly are sometimes described as

Natural Language Control as used in Cognito2
9
moving in an organic manner or looking like they are operated by a follow-spot
operator. People are quick to forgive the fact that they are always moving in this
arc pattern. Natural Language Control gives you the option of how the light will
move. It doesn't have to move in an arc. When a follow-spot operator moves a
light from point A to point B, the light normally travels in a straight line.
Cognito has a Positon attribute called P/T Mode that alters the way fades are
calculated when you advance from one position to another. If you record a
memory or a cue using specific Pan and Tilt values and specify the P/T Mode to
be Linear Movement, the end points of the move do not change, but the
intermediate steps of Pan and Tilt needed to get from the first position to the
second position do change. It becomes a transition that forces the Pan/Tilt
mechanism to travel the beam of light in a straight line:

10
Zoom Example
Programming lights using real-world values allows you to swap one fixture for
another and get predictable results. Far more useful is the fact that the same
values are used to control different types of lights in a similar fashion. Looking at
the zoom attribute demonstrates this again.
It is quite common to have two or more different types of lights in today's lighting
rigs. Matching beam sizes is a process of grabbing one type of light, setting its
zoom, then selecting the other and tweaking it to match. You cannot grab both
and crank the wheel and hope to get matching results. Natural Language Control
eliminates this unnecessary practice.
Here are two lights; one that has a zoom range of 19° to 70°, the other from 10° to
50°. Cue 1 calls for the lights to use a zoom of 20 degrees:
All you have to do is turn them on and Cognito defaults them to the same value of
20°; they're already the same size! Your rig looks consistent and symmetrical with
no undesirable surprises and no need for manual re-translation. If you want them
to match your 19° or 26° or 36° fixed lights, just set the Zoom value to the
appropriate level.
If Cue 2 was written such that both lights go to 70° both lights would resize at the
same rate until the one on the right has to give up mid cue: