I've been spending some time on and off since the arrival of my console going page by page in the manual to learn stuff. This is different from what I've done prior, which is watch a bunch of YouTube videos and do the best I can with the software only. To that end, I want to write about that experience periodically, because I don't think the documentation is very good. As a technical writer, I don't think you can just make a list of buttons and say what they do. Unfortunately, that's kind of the approach they've taken.
This won't mean much to anyone who doesn't know the software, but I want to write some things down in the event that I have a better idea about how to teach it.
So far, I've covered everything except the sequences and executors, which I kinda get already, and the masters and phasers, which I don't have any tangible understanding of. That means that everything prior, like presets and groups, make references to the not-yet-covered parts. There's a bunch of stuff before that even that isn't super relevant to programming, including the networking and patching, not to mention the UI conventions, but the thing I take issue with is that they don't really cover concepts early enough.
As a software developer, I think this matters, because what they do is so deeply structured in the way that I would approach it as a developer. Everything is an object, and there's a graph of objects. Parameters make up fixtures, which can make up groups, and presets can set attributes on those groups and fixtures, which in turn can be referenced by cues, which are part of sequences, and several of the above can be assigned to executors/faders, and then phasers and masters (for dimming, timing, etc.) figure into all of those.
How do I know? Because I've tried to write the basics of this software. I did a talk on it. The object models used in the software are very much reflective of how I'd organize things as a developer. I'm not saying that's good or bad (yet), but for my engineering brain, I would almost rather that they described it in these terms up front. To understand the object graph is to understand how to build a lighting sequence for a real show.
Most importantly, they should talk a bit about tracking, which gets vaguely referenced early in the other concepts. Tracking means that from one cue to the next, as you move through a sequence, the state of any fixture only changes if you change it. In other words, one cue could turn on some lights, the next might change their positions and colors, but their dimming level doesn't change. The next may turn on different lights, but the others don't change unless you change them. This isn't really a concept unique to MA either, as the ETC stuff works similarly.
I'm spending time behind the console as time permits, but on my laptop I'm also trying to put together a small virtual demo stage for the purpose of messing around and applying what I'm learning. It involves about $150k of virtual lights! I've got four physical lights in the room, and that's fun, but to do more serious things, I need more to work with.
No comments yet.