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:

Natural Language Control as used in Cognito2
11
The light on the left would complete the cue zooming all the way to 70°:
To be fair, Cue 2 could not have been written using the light on the right. This cue
must have been recorded using a light that can achieve 70°. Even though in this
example it was played back using a 50° light, it does not change the cue. If you
later swapped it back to a 70° light, it would go to 70°. It is only when writing cues
that you are limited to the physical constraints of the light currently patched.
Shutter Control Example
One of the most time consuming endeavors when programming moving lights is
shutter control. To achieve desirable effects, the shutter mechanisms need a lot
of motors, and hence, a lot of control channels. Typically, most shutter assemblies
have nine motors. There are four shutters, each using two motors to control its
position within the aperture of the fixture and a ninth to rotate the entire
assembly clockwise or counterclockwise. Many times these channels are labeled
like this:

12
The oval in the image above shows how the light would fall on stage if the fixture
was hung in a typical Front of House position. You can imagine that trying to
make shutter cuts can be a time consuming effort of hunting and pecking for the
right channel or more likely, pair of channels. That is why Natural Language
Control groups related pairs together into useful names like Top, Bottom, Left
and Right.
In the example shown below, the console is driving a Vari*Lite 1000 fixture.
Cognito conveniently places the thrust controls on the two wheels closest to you

Natural Language Control as used in Cognito2
13
(red and green) and the respective angle controls above those. One wheel
manipulates motors 1a and 1b in unison to Thrust the shutter into the aperture of
the fixture. The yellow wheel above that adjusts the relationship between those
two motors, giving you one handle for controlling the Angle of that shutter. If you
rotate the yellow wheel to the right, the shutter rotates right:
Note that the Thrust is measured in percentage. Most moving lights only allow
you to put the shutter part way into the field of light. Above you can see the Top
Thrust for the VL1000TSD is set to 25%, but its maximum value is 80% (not
100%). That is because the VL1000 physically can only cut out 80% of the beam.
The angle is limited to -35° to 35°. Conversely, the VL3500 can only push the

14
shutters 47% of the way into the beam. By using a percentage unit to describe the
position in the aperture and degree units to describe the angle, you can copy the
shape of a shutter cut from one type of moving light with one set of physical
constraints to another with predictable results.
In the example below, the value of Top Thrust is set to 50% and the Top shutter is
cutting the beam in half. The Right Thrust cuts 15% of the beam.
Gobo Control
Individual moving light manufacturers' implementation of gobo control is
frustratingly inconsistent. There are so many things these modern machines allow
us to do, but there has never been a consistent method of describing what they
do. Natural Language Control attempts to pull in the reins and consolidate on a
common language of control.
The assembly that holds the entire gobo selection is called the Wheel. Wheels
can Spin Forward or Reverse in Revolutions per Minute (RPMs) or can Select
individual Gobos. Gobos can be Indexed in Degrees like hands on a compass
or Rotated continuously Clockwise or Counterclockwise again at a specific
RPM.

Natural Language Control as used in Cognito2
15
Different manufacturers use a variety of control channels to achieve all of these
possible behaviors. Some use lots of channels which surprisingly makes the
control of the gobo wheel easier, and other insist on bunching up behaviors on
only a couple of channels. The examples below are generic and are only used to
show how it could be done using linear DMX512 channels compared with how it's
handled using Natural Language Control.
The first of the pair of these linear channels is used to position the wheel and
select a specific gobo and do one of two things with it; either Index it or Rotate it.
The second channel changes modes based on the position of the first. Here the
first channel is set to about 10% and Selects the Dots gobo for Indexing. The
second channel is set to about 10% which indexes the gobo 15°.

16
Remember, the fader doesn't show you these options as selections - you need
to know them in advance! In contrast, Cognito's display shows Gobo 1 Wheel
Mode (yellow wheel), Gobo Select (red wheel), Gobo Mode (blue wheel) and Gobo
Index (green wheel). And, as well as showing "Dots" as the current selection, you
can see that moving one 'tick' forward would give you "Pinwheel" and one tick
backwards would give you "Open":
To rotate the Dots gobo continuously in the clockwise direction, the first handle
must be placed at 60%. That changes the mode of the second handle and the
10% position is now meaningless. To see a rotation of 4 RPM clockwise, the
channel must be set to 30%. (Where that value comes from is completely
arbitrary. Truthfully, you would never get a answer even if you were to visit the
factory and ask the firmware engineers!)

Natural Language Control as used in Cognito2
17
The same information is shown on Cognito's display like this:
Changing the direction of the rotation on a DMX based system means you must
travel the second handle through a bunch of values that are of no interest to you.
The gobo would slow down, then stop, then change direction and speed up again
as you adjust the control channel. This can be very disconcerting for a designer
who is watching the stage. None of those behaviors were asked for, but were
necessary to reach the desired result.
With Cognito , you just nudge the blue wheel one tick to change the value from
Rot CWto Rot CCW. The green wheel, which controls the speed, is not
changed. The DMX values will jump from the value for clockwise rotation at 4
RPM directly to the counterclockwise 4 RPM value (whatever that is).

18
Again, this is how it looks on Cognito's display when programming:
Conditional Abstract Attributes
Automated lights are riddled with control parameters. In earlier days, many fixture
manufacturers combined DMX512 channels to achieve separate effects in an
attempt to prevent the fixture from consuming an outrageous number of
channels. A common practice is to use one channel as a mode channel to modify
the behavior of another. This makes life difficult for the lighting programmer as
he never knows what a handle will do without first checking the state of the mode
channels.
Natural Language Control eliminates this need for reference by not presenting
you with controls that are ineffective on one channel because of the state of
another. The Control Task separates the tools into one of four attribute families:
•Intensity (amber colored tools)
•Color (purple colored tools)
•Position (green colored tools)
•Shape (pink colored tools)
The various tools in the Control Task allow you to adjust attributes without the
fear of inadvertently affecting the function of another channel. Furthermore, the

Natural Language Control as used in Cognito2
19
Wheels tool, which is common to all attribute families, labels each control
appropriately as to what it is doing at present based on the state of other
attributes. Complex gobo wheels are a good example of how this is put to use.
DMX512 mapping and the number of DMX512 slots used by the light have
nothing to do with how the controls are laid out to the user.
In this example, Gobo 1 Wheel Mode (yellow wheel) is dialed to Select, the
current Gobo Selection (red wheel) is Alpha Rays, the Gobo1 Mode (blue wheel)
is set to Index and the gobo has been Indexed (green wheel) to 45°:
If the user were to adjust the control labeled Gobo 1 Wheel Mode (yellow wheel),
the entire gobo wheel would Spin Forward (or Reverse). If so, displaying the
control that allows you to choose the Gobo Selection would be pointless; the
entire wheel is spinning through the light path, so you will see all the gobos, not
one at a time. The layout is changed to reflect this:

20
Shown on the red wheel is Gobo 1 Wheel Speed which has been set to 10 RPM,
and green wheel has Gobo 1 Mode set to Index preventing the individual gobos
rotating. This is where Natural Language Control keeps you out of trouble by only
showing you what's possible. The planetary rotation of the larger wheel makes the
individual gobos on the smaller cogs appear to rotate around the larger wheel's
center axis. Mechanically, you can't prevent this from happening. That is why the
Wheel Mode is Spin and the Gobo Mode is Index you are not shown the
corresponding Index attribute (which was set to 45° above).
When you do want a lot of gobo action (gears turning in gears), set the Gobo 1
Mode attribute (green wheel) to Rot CW (or CCW), and appearing on the blue
wheel you will see a new Gobo 1 Speed attribute (blue wheel) which is set here to
5 RPM:
Changing Gobo 1 Wheel Mode (yellow wheel) back to Select will once again
allow you to choose a gobo with the lower left control and in fact Cognito has
'remembered' that the last gobo you selected was Alpha Rays: