The stage production of Mary Poppins, adapted from the stories by PL Travers and the Disney film, opened at the Prince Edward Theatre in London in December, after an out-of-town tryout in Bristol where the show was rehearsed. Directed by Richard Eyre and designed by Bob Crowley, the show's lighting was designed by Howard Harrison; I served as the show's lighting programmer.

As with almost every show I've worked on over the last ten years, we chose to use a control system based around Strand Lighting 500 series control consoles for the production. These consoles have always done what we've needed and been utterly reliable. On these pages, we present a pictorial guide to the way we used the Strand consoles on the show — a console's-eye view, if you like — giving you a look at how we used the equipment to deal with this complex show. The console now controls 115 moving lights, including ETC Source Four® Revolutions, VARI*LITE VL5Bs, VL2000s, 3000s, and 3500s, around 200 ETC Source Fours®, around 140 Rainbow color scrollers, 45 four-color fluorescent battens, three Hippotizer digital media servers, two beaMover moving video projectors, plus a whole range of extras from star cloths to confetti drops and even a collapsing table!

The challenge here was different from rock-and-roll type shows with big moving light rigs. This was a linear show running to about 400 cues with the intention that, for the most part, the audience was never aware of any of the light moving. In addition, Eyre is hypersensitive to noise, so we had to minimize the noise of the rig. Where big scroller resets were required, loud parts of the show were carefully chosen. Finally, the show is operated by many different people. The programming had to allow the show to be maintained easily and make it obvious to those running the show what was meant to be happening — to be self-documenting as much as possible.

If you use Strand consoles, this might give you some tips for stretching your console further. If you use other consoles, it might offer some suggestions as to ways of dealing with large rigs on complex shows.


Strand consoles can be configured in many different ways. We're set to GENIUSPRO (the default for consoles in Europe), direct one digit (1@5 sets channel 1 to 50%, no need to press enter, so less typing). The STOP key is set to STOP ATTS, which stops any attributes (pan, tilt, etc.) moving — an e-stop of sorts — important for working near increasingly bulky moving lights. Cue Tracking is set to ON. We're running the cue list on a single playback, and Strand's Auto Move function (which presets moving lights automatically) is OFF. I prefer to have control of when lights set, particularly when working with a noise-sensitive director.


The rig uses ten streams of DMX, so we're using Strand's ShowNet Ethernet network to carry the data from console to stage. Five SN110 network nodes convert it back to “real” DMX for the lights.


DMX stream 1 drives the house dimmers. British theatres generally have installed dimmers. I've created a profile to match the Prince Edward's Bytecraft dimmers to the ETC Sensors on which we plotted the show in Bristol. I'd matched the moving lights fade curves to the Sensors. In London, they provided the control to match the Bytecraft dimmers.


Stream 2 fed the Rainbow scrollers — color is Strand's attribute 2, so stream 2, address 49 is the scroller of channel 441. The green 25 shows that these are 26-color (25+frame 0) scrolls. To minimize fan noise, we used the fan speed function on the Rainbow scrollers, patching the fan to the lamp's intensity, so the brighter the light was, the faster the fan went; profile 39 corrected the scroller's default behavior (0-fan at full, FL=fan at minimum) to the behavior we needed.


Here are the ETC Revolutions, patched on stream 6. Our units had the rotating gobo module and the shutter module, so some of the units' DMX channels are blank, as they have no function. Note the profiles: 15 to match the dimmer to the rest of the rig, 36 to control the behavior of the color scrollers. I created different fixtures for apparently identical lights — units on stage left and stage right ladders, for example. The different units had shutter control attributes arranged differently, so that moving the same encoder on the console brought in the same shutter on stage (the upstage cut, for example), even though it was actually a different physical shutter because of the lamp's orientation. We also arranged for the four encoder wheels to control opposite shutters (two encoders per shutter) rather than adjacent shutters, the arrangement manufacturers adopt by default, which is usually less useful. Pan and tilt inverts were also used, where required, to make all of the lights move in the same direction under trackball control.


On Strand consoles, channels that you don't want in the show can actually be deleted from the show file entirely. In some displays — this is LP+, which is Light Palette+scrollers — a vertical line is shown on the screen, giving a visual break between different blocks of channel. The show's channel numbering was designed to take advantage of this: 1 to 7 are the digital light curtains; 11 to 16 are VARI*LITE fixtures on lighting bar 1; 21 to 25 are VARI*LITEs on bar 2; and so on. All lights, moving or conventional, are just channels in Strand world. Channels up to 220 are moving lights; beyond that are conventionals, some of which have a scroller and, therefore, a color frame number below their intensity. The dim gray channel numbers are units cut from the show and so no longer patched to anything. In time, they will be deleted.


Strand consoles use Groups in two ways. Groups 1 to 750 can be used as reference groups: setting a channel to a group in a cue looks up the value in the group whenever the cue is run. This is what other consoles call preset focuses or palettes. I start with colors, all matched back to real colors from Rosco and Lee, since they're much better at making consistent colors over time than the moving light companies. The list with moving light color mixes is imported from earlier shows (usually while working at home on the off-line editor software), and any new colors in this show's scrolls are then added. I'll then make versions of these new colors for the moving lights, so later, I can grab any lights and make them go to that color. The names allow me to select colors at the keypad, typing just enough to make a unique match (here Rosco 03, which is frame 13).

Later come custom colors created for particular moments in various shows (“Kim 2” probably imported from Miss Saigon!) The scrolls in Poppins had three frames of open color, requiring separate groups. Colors are followed by settings for other parameters — for example, edge focus, zoom size, gobos, gobo rotation speeds, and so on.


Groups above 750 behave as in other consoles (for selecting combinations of channels). This also provides a useful way of labeling the channels within the console, saving the need to dive into Lightwright if you can't remember what something is (such as channel group 969.2, channel 3011, the Doug Fleenor Coffee Pot acquired at ETS-LDI). Documenting things is an important consideration on a show that will run a long time, be operated by many different people and, hopefully, go on to a future life in other productions.


In the old days, preset focuses were used to get groups of lights to one position: “all to the drummer,” for example. For position, I tend to use reference groups as labels, explaining what a light is doing. I start with a collection of general positions (backlight, x-wash, 3/4 backlight) to get us going and for big washes, and then I make special positions as they're needed by the show. If I try to do a grid focus, I find that there are lots of grid squares I don't use, but those that I do use are never fine enough. This may mean that a position group only contains information for one light, and a cue may, therefore, contain lights set to many different groups. The “magic update” function (which figures out which group of lights were set to update those groups automatically) means that maintaining such cues is still easy.

I then use separate groups for position, color, gobo, edge focus, zoom size, etc. These are useful for making different types of lights behave in the same way (i.e., to make all of the lights go to sharp focus on a gobo) or to make lights in different places behave the same way (i.e., go to the same iris size, despite different pipe trims). I tend to store gobo indexing and shutter shapes in groups with position since, if the position of the light changes, the gobo orientation and shuttering will usually also have to change.

Overall, my aim is that someone who doesn't know the show or has never seen the show can get an idea of what a light should be doing just from the screen (up center, in red, in dots, in sharp focus, for example). That way, if the light on stage is in green, the operator knows the light has gone wrong without having to refer to anything else. If more detailed information is needed, the moving light focus database will provide it.

Point group numbers don't count as reference groups, and they are useful as spacers between blocks of groups or for storing old or alternate versions of focuses.


I've set the console's submaster bump buttons to be Macro buttons instead, giving me more buttons for direct access to gobos and colors. I've also made inhibitive submasters for parts of the rig I might want to pull out (all of the conventionals while doing moving light focuses, for example) or that I might need to hold out (the upstage ladders that sometimes get caught by scenery and are left- swinging).


Macros are the heart of 500 series consoles, allowing any command sequence to be automated. The “@GROUP” macros are used by the bump buttons to select gobos, colors, etc. Typing the macros looks daunting and is dull, but it only needs to be done once. They can then be moved from show to show, since the console can load any part of any show into any other show. Macros 1-9 can be accessed directly from the keypad — a useful shortcut. I use the LCD macro keys as Beam Open, Color Open, and Home — a quick way of getting lights back to a known start position.


When cues are first created, RECORD is used (or REC-SUBS is used to record the cue ignoring any subs that are up). After that, Strand's multi-function UPDATE command is more useful. It can store modified channels into the current or any other cue, tracking or not, or even tracking backwards. It can selectively store channels or attributes into cues or groups. Best of all, it can “magically” update preset focuses: with 50 lights set in 50 different position groups, move all of the lights, then just UPDATE GROUP. The correct position is updated for each light — perfect when you're moving a show from one theatre to another and working through it cue by cue, as you can just fix the look of the cue without worrying about the structure of that cue.


The console allows you to move information from just about anywhere to just about anywhere else (“set those lights as they were in cue 10”). ATTSONLY is a global filter that just selects attributes without the need to type “pos,” “color,” “beam,” etc.


The console also allows you to work in blind while still holding a modified state live on stage, so while the designer is pondering more changes to a cue, I can jump into preview and make other changes or fixes. I have the PREVIEW FOLLOWS LIVE option set to OFF, so hitting preview takes me back to wherever I last was in preview; CUE PREVIEW will preview the current cue instead. Usefully, I can also pull current live settings into a cue I'm editing in preview. This is a great way of presetting moving lights, scrolling back a few cues then setting just the attributes to the look you've just set live on stage.

My approach in theatre is that, once a look is set, you should be able to fix and preset it without moving things around and distracting the actors who are rehearsing on stage. I also work as much as possible to ensure that, during the show, lights only move when they have to (to reduce both noise and wear-and-tear), so any moves that have become redundant are tracked out, and presets are tidied up and moved to loud points in the show when the band or moving scenery will mask moving light and scroller resets. Being able to work freely in blind means that I can do this during what might otherwise be dead time during rehearsals.


The console also offers many tools for making block changes through cues, from “take that light up or down 10% through this range of cues” (invaluable when changing theatres; the console has the sense not to bump channels at 0 up to 10%) to “make this light do the same as that light does” (invaluable as a large musical evolves). The view shown here is the XREF spreadsheet view following channels through cues. The black background to the scroller frames shows they are set using reference groups.

Update allows levels to be changed by percentage steps — “up 10%” or from one value to another (from 50 to 60, from red to green). The AutoMod, or automatic modification, function allows scaling (“10% brighter”) and works through groups as well as cues, giving you the ability to clone or renumber gobo and color information when first setting up a show or when later adding extra lights to a rig. It can also make changes on-the-fly, without the need to alter any programmed cues — for example, replacing one lamp with another for that night's show if a bulb blows.


Strand's consoles support multi-user operation, with partitioning for playback and channel-control separately switchable. In early plotting, show electrician Alex Peters ran a second console connected as a remote, and he plotted conventional lights, while I dealt with moving lights. We both stored into the same cue numbers but could play back cues independently with Playback Partitioning on. The new LIVE mode for channel partitioning meant that, though we couldn't control each other's channels live, we could in preview. For example, I could preset his scrollers, while he continued working with the designer. This allows two programmers to collaborate on controlling a big rig, rather than working separately on two smaller rigs.

During previews, the system was reconfigured so that our main 530i console stayed in the booth, but the smaller 520i console was brought out into the auditorium and used as a remote console during afternoon lighting sessions.


Mary Poppins runs on a single cue list of about 400 cues. The aim in the cue sheet is to provide enough information to find scenes when working on the show and to let the operator know what should be happening when running the show.

Strand consoles don't have “timing per parameter” as some consoles do; you use “part” cues to have things running in different times within one cue, with each cue part having separate up, down, and attribute times. The advantage is that the part cues reveal the structure of what the cue is trying to achieve, and labeling the parts allows that structure to be explained.

I have self-imposed rules about what different parts do: part 12 is always used for setting moving lights, and part 11 is for setting scrollers, for example, making it easy to see what is happening when the show is running. In most cases, a lamp will fade out in part 1 over five seconds, for example. Part 12 will then have a delay a little longer than five seconds (since some moving lights don't actually quite fade out in the time they should) and a zero second fade time.


Generally, I set moving lights in zero time because, for many brands, this seems to give the most accurate positioning and, in many cases, provides the minimum distraction. If an audience member notices a light move again, it is still by the time they can really focus on it. When live movement is required, I use the lamp's timing channel, particularly on VARI*LITEs, to give the smoothest possible movement. Again, my self-imposed rules dictate part 6 setting the timing channels in zero seconds (using reference groups that store the appropriate time parameters), then part 5 snapping the light's attributes to their new value after a fractional delay.


On big shows, the lighting console ends up doing lots of unseen things, such as dimming FOH conductor monitors and switching on parts of the rig as work light. I use part cues and reference groups (setting the intensity to a level stored in a reference group or a moving light to a work light position) so later on, I have a reminder as to why lights upstage of a cloth are on. Using intensity in a reference group also makes it easy to make the work light brighter globally through the show. For the same reason, using intensities in reference groups is a useful way of making chases.


During technical rehearsals, the show's video content had a separate control system using a Hog® PC. By the end, though, the video content had been reduced to a level where it seemed silly to have another computer system sitting around to control it. So, I made fixtures for the Hippotizer media servers and beaMover video projectors, then we connected the Hog to the 530, set one DMX port to be DMX IN, and used the chan@COPYFROM DMX command, which brings in DMX through the softpatch and makes the correct values appear in the fixture on the channel screen. There was a slight catch when I discovered that DMX IN only worked on stream 1 (I last used this function in 1996 when having two DMX streams was considered a lot), and the Hippotizers were patched in stream 10. Fortunately, the console lets me move sections of the patch around easily, so I just moved stream 10 to stream 1, captured in all of the Hippotizer data, then moved the patch back. We then sorted the captured values into reference groups to make it clear what each cue was doing. The console's @DMX level command, allowing values to be set as 0-255 rather than 0-100, has also proved useful when dealing with media servers.


Mary Poppins is a big show, and the show file doesn't fit onto a floppy disk. We added an Iomega ZIP drive to the console. Even quicker, we connected my Macintosh laptop, running the remote console software under VirtualPC, to the Strand network and saved it from the console to my Mac. Even quicker at the end of a long day, we pulled it from console to Mac using Strand's ioftpdos utility. From there, I backed the file up to storage space on the Internet, so there was always an off-site version in case of complete disaster.


Designers have become used to having channel and cue information available on their production desks, and video nodes from ETC and Strand have long provided an easy way of providing such displays. The trouble is that these nodes just copy the console's display, but the LD doesn't really want to see all of the behind the scenes work a programmer is doing. They just want an overview of what the lights are doing. For Mary Poppins, we used Strand's xConnect remote video program running on the Macintosh laptops of Howard Harrison and his assistant, James Whiteside. Each could configure his own display, which was completely independent of what was happening on the console.

For Howard, we set up two windows, one showing the cue list, the other showing channels in GALAXY+, COMPACT format. GALAXY+ shows the channel numbers vertically with the whole channel number always showing (some displays remove the hundred digit). It also shows the color reference group name, rather than the frame number, so he could see that a light was in “202” rather than “frame 10.” COMPACT mode only shows channels that are on, reducing the clutter on screen and removing the need for him to page up or down through the displays, or he could even have multiple versions of the channel display open in different formats. In Bristol, this all functioned over a wired network and in London, wirelessly.


Once the show is done, there's still tidying up and paperwork to be done. The console's REPORT function allows cue parts or channel usage to be checked. More quickly, the CUE a THRU CUE b @FULL command (in preview, not live!) creates a cue showing what's actually been used. Equipment left unused can then be derigged, while the channels can be deleted from the console.


This just leaves the job of notating what all of the lights — particularly the moving lights — do during the show. Some have a tracker to do this during rehearsals. I make notes as we go but prefer to do it at the end. Digital cameras have revolutionized this, allowing pictures to be taken showing exactly what a light is doing, then merged into a database (created in FileMaker Pro) detailing when it's used (so you can get a listing of lights used in a particular cue) along with a description of its function. Extracting the “when used” information from the console into the database used to be a laborious manual process. It can be helped by getting cue and group information from the console (by printing to a text file then transferring to the Mac or PC or using Strand's Showport utility).

For Poppins, I'm trying an automated process developed by programmer Matt Peel at the Royal Shakespeare Company, which seems to be a great time saver. Hopefully, future consoles aimed at theatre might remember our need to document everything — why not let us plug in a digital camera and have it take a picture every time the record key is pressed?