I spend a lot of time trying to figure out better ways I can to train students. Last year I came up with a long form way to learn programming directly on a console that I’ve tested several times and found good success with. But lately, some new iPad apps have been making me question if there’s another way. Allow me to walk you through how I learned to program with some historical/technology context added so you might “smell what I’m cooking”.
When I started programming, computerized lighting consoles were in their adolescence. I was able to command lights and record cues from the numeric keypad and other buttons, but things were so much simpler. Why? The only thing that existed to control were dimmers. Yes, there were scrollers and gobo rotators, but the console didn’t know what they were- to the console, they were another dimmer. Typically there was one to a max of four universes (1-2048) of dimmers, depending on the console and the gig. One parameter of control per light is a pretty simple task, but it sure didn’t feel that way at first. That’s partially because learning the console is only one part of a fairly large job. Other things to learn? How to communicate with designers/gaffer, the every day working methods of stage and film, lighting angles, how to work around Scenic taking all the time and space, tracking, organizing channels and cues across a script, updating or moving cues, basic color theory and millions of other things.
It was later in my life- about 7 years laters- that I finally was able to program moving lights. At first I programmed them on the same consoles that only see everything as a dimmer. It’s a trip and I recommend it as an exercise. It really forces you to understand the parameter “teamwork” that needs to happen to control any light out there. The effects engines in these early consoles were exceedingly simple and basically were just a list of instructions tied to each channel. Try to imagine creating a pan and tilt ballyhoo on a console with no wave forms and no awareness of which channel was pan or tilt. I spent a few years doing this.
Around 2006-ish, I started programming on actual moving lights consoles. The consoles were different from the “dimmers-only” kind, but still held some familiarity. All of a sudden (for me), the consoles knew what the parameters were on each light and what they did. There were color pickers and effects that were both list based and wave form based. We needed to decide whether to use an absolute or relative effect to accomplish our task and we were no longer tied to effects that only worked on the channels you used to create them. It was awesome. But as always- with great power comes a ton of crap that confuses you while you are learning. With time and experience, I got quite good at this new-to-me kind of console.
Why did I give you this little history of my programming? Because it points out that I learned programming a lighting console as we now define it gradually and over time. I learned the social and working methods, that retaining any show I ever programmed was a silent expectation, basic color theory (then advanced), how to deal with designers of all sorts of working and communication methods, how effects engines work, how a profile truly functions, tracking non-intensity parameters, and above all- the service aspect of being a programmer. Today, because we have these advanced tools, this is a LOT for an aspiring programmer to learn all of a sudden and all at once.
One last seeming derivation that I promise is very relevant. When I train people, I’m typically engaged to teach students four continuous days of seven or eight hours a day. The single biggest determiner that I’ve identified in how much you get out of an extended training with me is how much experience you have before walking in. If you’ve programmed very little- the first two days will be an intense experience, but worthwhile. The last two days will be an overwhelming overload. Experience is vital, but how can a new programmer get it when there is so much to learn?
Finally, we have arrived at my new approach on how to teach new programmers (especially film programmers). With Sidus Link Pro being out in the world (even though it’s not a full release yet), I think the answer is to start with object-oriented programming, then work your way up. If you are not familiar with Sidus Link Pro, it is an interface that is simple and direct. There are no channel/fixture numbers to be confused by- you just select a light or lights by poking them, then control them by dragging sliders. It’s about as simple as it gets. It has just a bit of sophistication in that there are ten faders to record content and use for playback. If you are new, you can ignore all the extra faders and just use one. But as you learn more- it invites experimentation with multiple playbacks controlling the same lights.
Sidus Link Pro is limited to 4 universes of control. This, for a new user, is ideal. You CAN get lost with only four universes of lighting (I’ve done it), but it’s much harder to do than with 64 universes. Last benefit- and this one is huge- it’s inexpensive. The cost of entering lighting programming can be huge and a simple rig and the computer and software to support you can easily run $4000-10,000. Sidus Link Pro is $10 a month for one universe and $20 for all four universes. And since it is simpler, it takes less time to learn and allows you to get on set and working on smaller jobs to gain the knowledge and experience that you need about the service of programming, gaffers, etc.
So my new proposal for learning to be a programmer is:
- Learn an Object Based console like Sidus Link Pro and go out and program as many gigs as you can. Do this until the limitations of the software are holding you back.
- Learn a simple console next. Blackout app or Chamsys QuickQ 40 are my suggestions. They are MUCH more complex than Sidus Link Pro, but nowhere near as complicated as a full console. Work as many gigs as you can until the limitations are again holding you back.
- Learn a full console. I have opinions on which console to choose, but I’m not sure they are helpful.
I like this approach because it is gradual and gets you earning money and acquiring experience while at “lower” levels of being a programmer. It ramps up costs as you progress as well. Of course, you’ll still need a computer with drafting software at some point (it’s difficult to identify when exactly this needs to happen, but I trust you’ll recognize the moment it does). When you finally attend training for a full console, you’ll have a ton more context to make learning the simple tasks easy and therefore you’ll have more capacity to take in the advanced stuff. Important to note if it’s not already obvious- when you are at each level of programming- clearly communicate to your possible employer which level you are at and what console you are using to frame expectations. Don’t sell yourself as an experienced programmer when you are early in your career and you can only control 4 universes at a time. That would be very bad for your career- which will be almost entirely built on word of mouth if it’s anything like mine and my programmer friends.
I’m going to start teaching this methodology this year and I’m really excited to see how it goes. If you are an educator and you have another way of approaching teaching programming- please share it with me in the comments. I love hearing other people’s approaches as I am always trying to improve. If you are student at any level, and all of us started out that way, please share your experience of learning- both what worked and what didn’t. It’s invaluable for the same reasons.
***
Mark LaPierre is a programmer in film and television based out of Albuquerque. He grew up in live entertainment and has been a designer/programmer for musicals, concert dance, live music, circus and corporate. Mark is a proud member of IATSE, an ETC Eos trainer and an enthusiastic trainer of many other platforms and subjects. If you enjoy his content, please consider commenting on his posts on the website to appease the Algorithm.
2 comments