Theater For The Future

Laura at Trailing Spouse Blues tuned me into this article which is just a wonderful working example of the theory at the core of this blog: that an open sharing of information leads to a “bigger pie” - more influx of thought, funding, and participation in theater, which leads to a reinvigorated and strengthened theater community.

When you share your knowledge you strengthen your industry and gain unexpected rewards.

I’m certainly not suggesting Coke publish the secret formula on their web site. But for a creative person sharing knowledge, especially business knowledge, will help the community has a whole.

The more knowledge amateurs, students or beginners have the greater their ability to make quality decisions. People can’t be forced to follow best practices or charge a professional rate for their work. But, more often it’s a lack of knowledge and experience that leads to such poor decision-making.

It’s hard to let go of the knowledge that we think is at the heart of our success. The note-taking system I detailed in the last post is an example of something that I do to help keep me as organized a sound designer as possible. I think it makes me better able to cope with the demands of a sound designer - where you must overlap many shows at a time in order to pay bills. At those times, it’s important to remember that our knowledge - which is the sum total of our history of choices, experience and conclusions of that experience - is both valuable to a newcomer, but it is also build and really only works for our brain. People can take your open-source knowledge and they necessarily will reshape it to their purposes. Virally, new thoughts and solutions will be created that you wouldn’t have dreamed possible. At the same time, those new thoughts wouldn’t have been possible without the seed of your own knowledge.

Sharing your best practices extends the collaborative ethos of theater into your business, not the other way around. It doesn’t guarantee the success (or domination) of a particular individual or a particular company, because it doesn’t guarantee ‘credit’ - it strengthens the entire industry first.

When I first started designing, I took handwritten notes. Scribbles, really. Each note said something like “dloor up 7 after…” I have horrible handwriting under pressure in the dark. Also, I didn’t write very quickly, so I’d leave a lot of trailing sentences as the play progressed and new cue mishaps grabbed my attention.

Frankly, I didn’t yet have a process, and I was designing in a panic. I used notes as shorthand to trigger my memory of what happened particular run, and then doing the notes meant reconciling that memory with the director’s divergent memory and then taking an appropriate measure to correct that cue for the next run.

The problem with me and this method became clear the first time I designed my annual summer juggernaut - the ten repertory shows of Cherubs. Each show ran an hour, and teched in an hour and forty five minutes. After tech, I would have one dress run to make any last adjustments, and then performance. Each night you tech two shows, and then the next night you tech two more. At the end of my first week of Cherubs tech I had a pile of incomprehensile scribbles like “Fade out the drone when she does that thing upstage” with little memory of the play itself. I needed a better way.

And I didn’t just need it for Cherubs. I looked at the designers whose careers I wanted to emulate - Andre Pluess, Lindsay Jones, Ray Nardelli, Josh Horvath. These individuals are unbelievably prolific, if you haven’t noticed. I think Lindsay pulled off something like 30 shows in 10 states last year. They worked everywhere, all the time - in Chicago and regionally. In watching their processes, I noticed patterns in how they organized their notes, cues, and files into standard formats and structures no matter how different the show was.

I experimented with excel spreadsheets and text files. The disorganization and lack of clarity continued - though I did notice that I had a speed increase and a greater percentage of complete sentences because I’m a faster typer. So I was capturing more of the same bad information I worked on self-discipline in the moment and looked into some preliminary shorthand lessons. It didn’t click with me. New problems started emerging as I experimented with new methods - I would bring a level up one day only to bring it down again after sitting in a new seat only to bring it up again after sitting in the first seat again. I was pushing and pulling my hair out.

The breakthrough came for me when I thought about the nature of the information I was trying to retain. Levels. Cues. Moments. Memories of the events of a run. Records of previous runs and notes. Whether I had taken care of a note or not. Notes from a director. Notes for a stage manager. Notes for myself.

I decided to create (ta da!) a relational database and see how that worked for me. I broke the information of my work into core models - cues, subcues (like fades and layered sounds in a cue), notes. Five years later, it looks like this:

Not the greatest interface, but it’s been built incrementally with only my brain, so it works great for me. Notes are in yellow there. As a show progresses, I scroll through my cue list. If I have a note, I just type in one of the yellow boxes and I have a quick pull down menu of basic types of notes to give me some quick context - “Director” means it’s something I need to ask the director. Its direct, and in practice, simple. I should note while the data structure is complex enough for me to use this system in every show, it’s also flexible enough that I can ignore great sections of it when time demands that of me. I really only use the subcue table, for instance, when I run using CD playback shows where overlapping sound files still need to be managed. Computerized playback often makes that paperwork more or less moot, so it just sits there.

By capturing the data I also noticed an immediate benefit - separating the data from the display of that data by taking it off a piece of paper or a spreadsheet freed myself to use the data in new and different visualizations. I could create a new layout that automatically created a cue list easy for a stage manager to read:

Or a quick pull list of notes to do in a hurry:

With six or seven shows and some troubleshooting, it became a system that I trust more than my handwritten notes and my swiss cheese memory. It became a way to freeze those pure, immediate reactions that I have in the space and in the moment and use those to inform my notes. And since I began analyzing the way that I captured information and the structure of the information that needed to be captured, my handwritten notes have become decidedly more disciplined and focused.

But that’s what works for me. What’s important is the way that you structure your own capture. You need a way to capture all the relevant data that you can fit into your bucket, and a way to intuitively and simply filter that information later. We are flawed creatures, and it’s not only possible but likely that at some point you’ll try to fool yourself into thinking you took one action when you took another.

There was another important capture that took place in recent months - the company members of the side project sat down and captured through a brainstorm all the roles and responsibilities of the company so that we could better enlist and provide support to Artistic Director and theater operations superhero Adam Webster. By capturing and filtering the things we did as individuals over the course of a season, we began compiling a bible of simple manuals for tasks and procedures that were involved with running a theater - everything from filing taxes to taking out the trash to repatching the lightboard. We took this information out of our cluttered minds and put it in a repository where anyone can come in and take over, and in doing so the problem of “running a theater” became smaller and more manageable. When you look at the life cycle of company membership, that kind of capturing and filtering process creates institutional knowledge that is the difference between the life of a theater company and its demise.

This is one of the reasons that I think creating a database of Chicago Theater is a worthwhile project and not simply navel-gazing. It is made up of collected and searchable and therefore endlessly useful data. If it is successful, it creates a model for other public resources of data in the theater community that by necessity would be more accessible than say, TCG’s data that Scott Walters used to such great effect. It captures hard facts that can be organized to suit your purpose that day. It allows us to check things that we believe are true (”You know what Chicago needs? A production of Our Town in April 2009!” They’ll never know what hit them!) against the captured data of collected memory that inarguably is true.

On a side note: Speaking of manuals, I’ve been exploring the utterly hilarious Poignant Guide to Ruby in my learning process of the Ruby on Rails programming environment for the CTDB. I think the devilvet in particular will appreciate the use of off-the-cuff cartoon foxes and elves to spice up the process of (yawn) learning a programming language.

When you’re reading and writing a manual, I cannot stress enough the importance of retaining your sense of humor. This is the thing that I often forget.

Some brief updates from the forge:

• Tech is going well. That’s the sound playback software LCS you’re seeing there. It’s pretty sweet - it’s the secret behind the complex sonic routing of things like Disney World, cruise ships, Cirque, and, well, the Goodman.
• You have like three days left to see Vivian Girls. Run, don’t walk, to Theater on the Lake at 7pm. I’m probably going to refrain from actually reviewing work on this blog, because 9 times out of 10 I have some sort of relationship or investment in the shows that I would review, but this show stands out. Dog & Pony’s opus isn’t simply a show - it’s an entire emerging genre of performance, and whether you like the show or not (you will) you’ll leave with your head abuzz with possibility. And no, you won’t be weirded out by the masks. You’ll dig it. Scout’s honor.



• The push is on for the Chicago Theater Database. Dan Granata and I have met with a number of interested parties, and it looks like the database will be beneficial to a large number of projects - and the Chicago community at large - without stepping on too many toes. As a result, I’ve taken the plunge to learn a new web development language, Ruby on Rails to simplify the development of the database. My head is swimming right now in: rake db:migrate Lions, script/generate model Tigers, and script/destroy controller Bears, Oh:My! If you’re interested in the project and less in the building of it, send a note. Why should you care? Because data is important: it helps us learn and know things for sure. Update: No, seriously, our data is important.
• The 10 scripts are in for “Cherubs,” a theater training program at Northwestern I’ve taught at for the past five years - a program that has been formative for me as a designer and a teacher. I’ll be designing these 10 shows in July with the assistance of 160 brilliant high schoolers from across the country (and sound designer/composer extraordinaire Steve Ptacek). Preproduction for 10 fully produced repertory shows built and run by teenagers is obviously an undertaking, of course. So those scripts and concepts have started swimming around in the kiddy pool of my brain with the Ruby and the LCS.
• So, as this season prepares to comes to a close, I’m finding myself knee-deep in delicious theater smoothie. Set to frappe. I’m glad I’ve got momentum as I ride around in the blender - and a full plate of projects that I think will do a lot of good for me, us, and the kids respectively. But of course it all means that posting here will continue to be spotty through June, and then blip out entirely in July as I pull daily allnighters - kind of like that period of radio silence as you round the dark side of the moon. But never fear - the summer always has this gravitational pull that flings me back out the other side with a new kind of velocity.

Continuing where Don left off, Mac over at SlowLearner hosts a debate featuring dv and the Chicago StreetBlogging Gang today… It’s interesting stuff, and it gets to the heart of a central question facing the (gag) theatrosphere.

It might help your theater understand what’s at stake when you choose to blog about your work or whether you can’t take the potential heat - and maybe how to improve the content you’re already putting out there.

It’s hard to determine sometimes if technology is making our creative work better and more efficient or just more complicated in new and different ways. Part of the problem is that for most of this decade software and hardware engineers were moving in the direction of modular solutions.

Instead of building great dishwashers, they theorized that it would be better to perfect the ultimate cost-efficient fork washer, leaving you to buy an equally astoundingly cheap cup polisher on a separate basis. This gave consumers (and designers) CHOICE - now you could save a TON of money buying the exact modules they needed separately and find new ways of getting the modules and devices to work together - or you could opt for a simple all-in-one solution that kinda sorta did what you needed, and you’d pay for the convenience. This is one of the reasons that your local designer on a budget looks like some kind of Max Max-era hacker with wild eyes darting from side to side looking for bargains and a magical toolkit of gizmos that will, you know, suture a pants rip in 10 seconds or diagnose whether a light isn’t working because of a broken lamp or because the dimmer load is about to make the circuit box explode.

In this chaos, it’s always refreshing to find a multi-use tool that makes not one but ten things easier to do. It means by using it you’ll be dumping a bunch of extra junk out your toolkit in a giddy and impromptu spring cleaning.

Here’s what it does
Chicken of the VNC is such a tool. It allows designers to do one thing and one thing alone: remotely access and control another computer over a network. Like a wireless network.

But here’s what it really means
Sound designers can be more active participants in the production process. I can sit in the house, experiencing the play like an audience member would, and be editing my qLab show file at the same time. If the sound is too loud, I don’t tell the SM to hold the run and high-tail it to the booth to twiddle a bunch of knobs or wires. This kind of behavior, let’s face it, undermines my credibility as a designer, because I’m stopping the show at every cue.

Instead, I nod at the director, and as they react to the loud sound, I turn it down, from wherever I am in the house. The stage, the balcony, the grid, whatever. With a little practice, I’m fixing the sound and resetting levels before they become a problem.

And voila, I’ve become a designer who has the tools to perform as if I was onstage, reacting to impulses and adapting the dynamics of the sound to better match what I’m seeing and hearing from the performers on the stage. I can design each and every moment of the play - silence through transition - rather than spending the time that I have on 30% of the play. I can react and shape rather than dictate in preproduction what the sonic world feels like.

Here’s how it works
I’ve set up in the booth a sound playback computer, which runs the increasingly excellent and free-as-dirt program qLab to route all my layers of sound files to the various speakers in the room. Normally, I’d have to do my programming from the booth or run some kind of umbilical cable to a remote keyboard and monitor. That’s a lot of crap to lug around from tech to tech compared to a single laptop.

First, I set up a computer-to-computer wireless network from the playback computer - simple as pie from the Airport menu of most macs.

Then, I connect to that network from my laptop, again through the Airport menu.

Boom! I launch Chicken of the VNC. After some initial configuration, the playback computer shows up as a VNC server on my laptop. Bookmark that, and then the remote screen is always just a few clicks away.

On my current show, A Red Orchid’s Not a Game for Boys (opening tomorrow!), there’s this ongoing ping pong tournament that is seen by the performers “behind” a plexi screen that is theoretically along the fourth wall. Getting the sound of ping pong and sneakers through glass to come from behind the audience required a large number of replacement files to get the reverb and equalization just right. But it didn’t mean frequent trips into the stamp-sized booth that can’t comfortably fit more than one person without getting in each other’s business and grinding rehearsal to a halt.

Instead, I connected to the playback harddrive using the computer-to-computer wireless network…

Then after copying the replacement files over the ether, I used my CotVNC connection to replace the files…

All while the SM ran a run without stopping.

Not exactly razoring reel-to-reel tape anymore, is it?

The half-life of technology is getting shorter and shorter, and so it’s not surprising that Chicken of the VNC is already obsolete. Apple’s latest operating system Leopard has included a built-in VNC client accessible through System Preferences. I gotta say - I love Apple for the way that they integrate incredibly versatile applications (VNC, Samba, Ruby on Rails) into their core operating system. Like many technophiles, I trust that if something out there is worth running, it’ll probably show up in my laptop next time I upgrade the OS.

I only use CotVNC as an example because, like the excellent and free FTP application Cyberduck which can be used to manage your theater’s website, it’s a brilliant program that does just one thing that will help you in a billion ways. Technology doesn’t replace human performance, however… doing the work well still requires practicing and rehearsing with the tools you keep at your disposal.

I love applications named after poultry.