Object Oriented Programming in the Theatre aka: why this is so weirdly intuitive

I think it is fitting introduction in a first blog post to choose a topic that ties in so nicely to my past. My background is in theatre, specifically in lighting design and theatrical electrics, which I did a lot of in high school and college. This has turned out to be oddly useful, not just because it has given me a great eye for well designed websites, but also because the process of lighting a show turns out to be a great example of/visualization for object oriented programming languages.

In the theater the theatre there are objects, lights, which for theatrical accuracy I’m going to call fixtures. The fixtures are totally interchangeable and don’t do anything until they are physically plugged into a specific socket, and which point it gets a unique name, usually the number of the socket into which it is plugged.

Once the lights are plugged in, they have a bunch of attributes that exist in the physical world, which for most lights are fixed: the location, the size and shape of the beam, the color, the focus. But there are other attributes that can be manipulated from the lighting console, attributes like brightness, and the speed at which the brightness changes. To control those attributes, the lighting designer basically writes a series of functions in the light console which will be run over the course of the show to produce the various effects.

Because they are going to be potentially writing several hundred functions, or cues, and manipulating several hundred fixtures, it goes much more smoothly if the fixtures are named systematically, so that fixture 102 is next to 103 is next to 104. Unfortunately more often than not, the placement of the pixtures and the sockets make it impossible, or at least extremely inefficient for even the most talented electrician to plug the lights into the sockets in such an orderly way. To solve this problem, there exists what is called a ‘soft patch.”

A soft patch is basically a hash in which the keys are called channels and the values are arrays. A fancy modern light board can have several thousand unique channel numbers, and all the fixtures are assigned to a channel so you end up with something that looks like this:

1: 203

2: 204

3: 354

4:321

5:631, 427

You’ll notice that there are two fixtures in channel 5, that is allowed. What is not allowed is having the same fixture in two different channels. One channel can have multiple fixtures, but each fixture can only belong to one channel. The cues are all written in terms of channel number, which means that if two fixtures are in the same channel they can no longer be (easily) manipulated individually, so it usually is only used for things like audience lights.

Once the fixtures are patched into the channels in a systematic way, so that no matter what the fixture numbers are, channels 102, 103, and 104 are next to each other, the cue writing begins. As I said earlier, writing cues is basically writing functions. The function for each channel takes the existing brightness of that channel, and moves it to a new brightness over a variable period of time. I don’t currently know the syntax to write such a thing, especially┬ábecause in modern light consoles you can actually adjust the curve of the change, so it isn’t changing in discrete stages, or I guess it is probably changing in really tiny discrete stages. Consider this a challenge all you theatrically minded hackers! Then you can probably just work for ETC.

This post wouldn’t be complete if I didn’t at least may a little attention to moving lights, which perhaps are the best illustration of programing attributes in an object. In a fancy modern moving light, with a fancy modern console, almost all of the fixed attributes in a regular fixture can be controlled from inside the console. The fixture now in addition to having the brightness attribute, has tilt and rotation position attributes so it can point in pretty much any direction , red, blue, and green color attributes for color mixing, a size attribute which controls an iris, a focus attribute which controls the lenses. Each attribute is set equal to a numerical value, which in turn equates to a specific physical state. So, when you change the attributes in the computer you can physically see the effect on the object.

The last thing I want to mention is that writing these functions is actually a lot like programming. Each board uses a slightly different syntax, but they do generally all go something like this:

Channel 27 @ 35 ##changes attribute channel.brightness to 35%##

Record Cue 102 time 3 ##writes the function cue 102 such that it take 3 seconds to complete the change##

The biggest experiential difference is that on a light board each word in the program (record, cue, time, channel) has it’s own button, so you don’t have to type them. I think this would be a very useful tool for app programming as well, it would require a lot more buttons though.

Peace and Light

–Julia