A Designer’s Eos Toolkit: Why build a template file?

In this series, guest blogger Cory Pattak discusses Eos show file setup from his perspective as a freelance designer. This week: Why is it helpful for a designer to show up for tech with their own Eos building blocks? How might a designer start an all-purpose template file that can be used show after show?

Being a freelance Lighting Designer can often feel like being a mountain climber. Every month (or couple weeks, if you’re a workaholic), you’re walking into a theater that you may or may not have worked in before, with people you may or may not know well, and attempting to put up a show in, usually, no more than a week. Hopefully you reach the summit, you celebrate a well deserved opening, and – not long after – you find yourself behind another tech table, at the base of another mountain, staring up at the peak, starting a new climb all over again.

It can be exhilarating and unpredictable, and, to some (including me), it’s a lot more rewarding than designing in the same venue over and over. However, it can also be exhausting. You often find yourself solving problems or performing tasks and asking yourself, “Didn’t I just do this last week?” and the answer is usually yes. You did mix that same color. You did make a music stand light sub. You did create a lightning effect. But, of course, context matters and now you’re in a different room, with different lights, on a different set, with a different programmer, on a different show.

The case for making a template show file

This never-ending cycle of performing the same tasks or always feeling under the gun eventually got to me and, after a particularly difficult show where I constantly felt unprepared, I decided to do something about it. Using the excellent tools available in the Eos software (and the ability to easily merge in data) I started creating a template file (now 4 years in the making) that would house all sorts of pre-made information that I could “carry” with me to each new theater/show.

Why should a designer be responsible for all this console stuff?

Before we get too far, many of you are probably asking “Isn’t all that console stuff the job of the programmer?” In a sense, yes. Unfortunately, we don’t usually get to pack our favorite programmer in our suitcase when we head off to do Crimes of the Heart in Sheboygan. I LOVE an amazing programmer. There are lots of them, and if you are lucky to work with one, you quickly realize how they can elevate a lighting design by leaps and bounds. Make friends with great programmers and use them as much as you can. However unless you are working on a major production (Broadway, Nat Tour, Out-of-town tryout), chances are you won’t be able to bring along your favorite programmer, especially if it means another plane ticket and hotel room. So, more likely than not, you are using a local programmer provided to you by the theater. There are also GREAT programmers in regional theatre, but programming is typically not their only job. They are often also the electrician, or the assistant electrician, or once for me, the marketing intern (true story.) And sometimes you will develop a relationship with a programmer/electrician only to return the next year and find someone new in that position.

Sometimes I do program myself, a decision which is arrived at by conversations with the theater about what will be the best solution for the show. None of what follows is to suggest the LD should also be the programmer, but in some situations, it may be the right move.

Crazy schedules, limited tech time

Regional theatre schedules are jam-packed with load-ins, one-offs, rentals, load-outs, meetings, etc. – and generally there isn’t much free time for these programmers to sit down at the console and really put in some hours developing a programming platform. In a typical production schedule, I usually arrive the day before focus to see a run-through (or we focus that evening), then if I’m lucky there is an evening or a day or two of dry tech/spacing time before the cast hit the deck. Once the cast is onstage, usually a couple of 10/12s, a dress rehearsal or two and bam – there is an audience.

There is usually no more than a week between the time I walk in the theater for the first time and there being a full house. This is not always the case, but it is the most common. This means there is often very little time to create the “tools” that are needed to quickly write a bunch of light cues. This was the problem I set out to solve.

Show file step 1: Identify frequently-recurring tasks

There were tasks it seemed I was performing over and over again. Some of these included:

If there was a way to have many of these elements pre-built, it could save hours and hours of time in every new theater, just getting to a point where we were ready to write Q1.

Point, counter-point: Whose job is it anyway?

Again, some of you are saying right now “But isn’t the act of creating those building blocks a good opportunity to feel out the programmer, assess their skill level, and start to develop a dialogue?” And again, I answer, “yes!” That can be a benefit to saving some of these tasks until they are in the theater.

However, some counterpoints:

A) Often there just isn’t the time to perform all those tasks before tech starts and cue writing begins.

B) You’re going to determine the programmer’s skill level at some point, that could be creating groups, or it could be recording the first 10 cues, so it’s not like that part of the process goes away.

C) Programmers hate feeling under the gun as much as we designers do, so if there is a way to ease that burden and let them know we’re not starting from scratch, they can breathe a little easier.

And, most importantly, this: nobody wants to throw a programmer under the bus. Nobody wants to blame a programmer’s lack of speed for the slow pace of tech. And nobody wants to have to solve a programming issue on the 2nd day of tech. If you’re walking into an unknown situation, there just isn’t always the time to “feel it out.” If the 30 minute side bar meeting at midnight is about your department, the damage may already be done. There are 101 things that can go wrong between focus and opening and probably will. If you can do something to make tech go faster, make the lighting department run smoother and more efficiently, and get to a better product with less stress and more taco dinners, why wouldn’t you?

Finally, I am also a big proponent of education, and I keep almost nothing close to the vest. (Exhibit A, this blog; Exhibit B, in1podcast.com, check it out.) There is no greater gift than passing on knowledge and I find that many programmers get energized about what the console can do when someone comes in and shows them ways to do things they didn’t know of or expedite their common tasks. Once they start using fun magic sheets, or useful macros, etc. they are often more likely to try their hand at building a suite of programming tools for themselves.

What’s in my template file?

So having said ALL that, I now have a master Eos file that is the bedrock of every show I design that doesn’t come with a highly-experienced programmer (which is 99.9% of them.) That file contains the following:

This was not an overnight process. This show file is a living document which is now nearly 4 years old. It takes quite a lot of discipline to maintain but it has 100% changed the way I design. It has changed what I can achieve in the theater, the speed at which I can create a design, and has done wonders for my blood pressure. More importantly, I can see the change onstage. My shows feel cleaner and tighter and more about the “art,” my show files are certainly much cleaner, and that night before tech, I now manage to actually sleep for a couple hours.

In the next few posts, I’ll walk you through the components of my template file and explain how I use them. Continue to Part 2: Patch, Color Palettes and Beam Palettes.