Skip to Content

Since people ask for these on occasion, here are some of the macros I’ve written. Feel free to use, distribute, whatever. I’ve written them for my own speed, they contain nothing that someone couldn’t figure out. Enjoy! You will need the predefined macro “World is Selection” for many of these.

Color generators

These are two color generator macros that generate the base palette of colors that I use for a show. It asks for two inputs, where to start (I recommend starting at 1) and where you want the “white” preset, which I usually put at 16. This macro assumes you have a full-width color preset window somewhere, or everything will look wonky.

CMY_Color_Gen_v31

RGBAWColor_Gen_v31

Dimmer / color wing effects

Very effective for strips of lights and battens. These are simple macros that set wing style 2 and then asks for a delay time, so you get a symmetrical wipe across your fixtures.

Color_in_out

Color_out_in

Dim_in_out

Dim_out_in

Concurrent Arrival Fans

These require GLADs IntelliVARs from ma-share.net. These align your fade opposite your delay, so your first fixture starts moving slowly, then next a little faster but a little later, and so on, so all fixtures arrive at the same time, but they have to speed up to get there. Two versions, one forward and one backward so I don’t have to reverse my selection order.

Concurrent_arrival_fan_1

Concurrent_arrival_fan_2

Here’s a list of things I wish grandMA3 would do, as we transition to it from MA2.

  1. Better macro editing. This is probably the biggest one. Currently, there are two ways to edit macros: in the software of the console, or directly editing the XMLs in a text editor. I have a powerful editor, Sublime Text 3, that works very well for this sort of this, especially with add-ons like Text Pastry. But it’s less than ideal for working with very large macros like my color generation macros. I had to make some major changes to one of those macros recently, and this was very painful because I had initially written everything as single lines (each color was generated by a single line of code, but each command was separated by a semicolon, to keep the line count down.) Unfortunately, if the fixtures didn’t have the attribute called by the macro, the whole line would fail, instead of just that one command. I ended up having to separate out the individual attributes into individual lines. This is a pain, because the code for macros looks like this:
<Macroline index="000">
<text>AddUserVar $FirstPreset = 1; Attribute "COLORRGB1" At 20; Attribute "COLORRGB2" At 0; Attribute "COLORRGB3" At 100; Attribute "COLORRGB4" At 0; Attribute "COLORRGB5" At 0; Store Preset 4.$FirstPreset "Lime" /g /m</text>
<info>Lime</info>
</Macroline>
  1. (Continued) I thought about trying to pull this into Excel / an Excel-like-program, with each cell a clipping of the macro line, but it proved to be too difficult to get the import and export correct. I still think some sort of plugin (or macro, ha!) for Excel could parse these files more effectively than I can make it do, and make editing easier. I’d love to be able to handle everything between the semicolons as “snippets” that I could drag around, copy / paste, etc, along with powerful enumerating features for renumbering (or even automatically keeping track of) macro line numbers, something I wish the console would do automatically anyway. For repetitive macros like this, that just do a thing over and over again, it would be a godsend. Or make them more human-readable, or something: seeing ” is like my bezerk button. It’s so unnecessary. There’s no reason that we must use XML.
  2. A GUI for the search / replace function. Search and replace is incredibly useful, though with the new recast preset function in MA3 its utility is probably somewhat lessened. It could still be useful for “replace all instances of preset x with preset y” which is a thing I frequently use it for. Having it in GUI form, with all the objects listed in two panes would be great.
  3. Waveform viewing on those panoramic screens. For timecode shows. That would be incredible! Drop a WAV or MP3 or AIF into the console, with a timecode track, and do all your timecode stuff in the desk without the need for an external laptop. Move TC events around based on the waveform, which would reduce the need for constant rewind / play / move event forward or back a few frames / repeat process that we’re all so familiar with. Bonus points if MA allows changing the waveform to a spectrogram view so that if you have a very “busy” song, sonically speaking, you could switch to that to see the events you wanted, separated by frequency.

I’m sure I’ll think of more, which I’ll put here.

Or, how to erode the popular support that has flourished for over two decades. Disclaimer, as always: these thoughts are my opinion, not science chiseled into The Granite Tablets of Truth.

A choice of console is a personal thing, as I’ve recently argued. For a while there, it seemed that there was only one game in town if you wanted to do big cool shows, that that game was the WholeHog.1 The II was and remains beloved for its innovative features and stability, serviceability, and longevity.

My very first tour was on a Hog. Well, sort of – it was a Jands Eschelon, but I doubt there was much different in programming in that desk’s software after the Flying Pig acquisition. I cut my teeth on that Effects Engine, learned how to write split timings and use curves. WholeHog II and, later III, was the jam in its day. That aluminum chassis was sexy. There was the dedicated jog wheel that slowed a cue down, or sped it up. That was innovative, and as far as I know unique. In fact, the hardware of the WholeHog III remains one of my two favorite. The machined parts were all very solid-feeling, the buttons were perfectly clicky, just the right amount of travel and feedback. The WholeHog software, though…is something…else.

I’m not talking about Hog III’s rocky start, which is well-documented and made a bunch of people upset enough to release some mean jokes that made some Flying Pig people feel Very Sad. I’m talking about the failure, over the years, and in particular with the Hog 4 system, to keep up with grandMA, and how they’ve fallen further and further behind.

grandMA has single-handedly come up with just about every innovation that we use as programmers all the time. Being able to do simple things like make your palette buttons small enough that your screen real estate makes sense lead to an overall better programming experience. (What was UP with those giant screen controls, HES? And the failure to update the look and feel makes WholeHog feel very…1990s, with all the faux-3D elements. I know, that’s nitpicky, but I’m here to pick some nits.) MA Lighting has also pushed the bounds of what you get when you buy into a console system: an integrated, and really excellent visualizer (grandMA 3D), a powerful effects system that continues to get better with each new software release, user profiles, worlds, and networking capabilities that make multi-programmer scenarios much easier to deal with. It’s also impossible, in any discussion of how grandMA has changed how we view lighting control, to not mention the macro system that has propelled grandMA to the prominence it enjoys now. The macro system can duplicate, as a script, virtually any function of the desk, with very few exceptions. This makes the macro system extraordinarily powerful, able to do everything from automating layout views, to a series of complex keystrokes, to just about anything else you want to do. WholeHog has a system that they refer to as macros, but it’s nothing like the grandMA system. The Hog “macros” can automate a few simple tasks, like releasing a cuelist or asserting another, but it’s fundamentally more limited than the grandMA system. Some of this might be due to internals: the grandMA GUI is mostly just that, a graphical interface over a core system that, at a fundamental level, is interpreting commands and keystrokes input from the hardware, and the macro system simply offers an easy editing interface and a way to script these. Hog – and this is speculation – might work somewhat differently, with no real “human-readable” command line existing somewhere underneath the software. That’s fine, as that wasn’t really a way that we thought about lighting during the years that Hog II and III were making inroads. (And by the way, I fully appreciate and understand that a skilled programmer with a lighting rig on a WholeHog 4, against an equally skilled programmer on a grandMA2, could make practically identical shows.)

It’s worth noting here too, that macros in grandMA aren’t just scripts. The user has two layers of variables can be set, show-wide and user-specific. Macros can pause to ask for user input, they can manipulate variables, and with a free Lua plug-in, can do math within variables as well, which makes this already-powerful system even more capable.

Hog tried, to a certain extent I think, to be the Apple of the lighting world: slick hardware, but limited ability to get into the internals. Their personality files for fixtures, for instance, are made by them, not you, and while the WholeHog console does include a confusing and rudimentary fixture builder, I never got it to work reliably when I was more regularly a Hog programmer, and I even had HES support people tell me “You really shouldn’t even try to use it.” Part of this difficulty might stem from the fact that Hog’s control scheme aims to be unified and “just work” – for instance, they aim to have a single button for each function. One to lamp on your fixture, one to reset it, and aim to avoid having messy personality files thrown together by people who don’t quite understand what they’re doing. That is a laudable goal and a nice feature2. But I believe that this way of thinking has really limited Flying Pig and later High End Systems (and now ETC, though I do not know to what extent ETC exercises control over HES control software development) ability to advance with the times. And therein lies my chief complaint with WholeHog as a control system: it has failed to take into account the innovations of MA (and others, to a greater or lesser extent) and implement them in way that would attract a new generation of Hog programmers, and to embrace the customizability and command-line power of other desks.

WholeHog improved in only small increments with further iterations of the Hog III and 4 OS3. Their Effects Engine stayed stuck stubbornly in the past, with about eight waveforms and little of the effects customization that grandMA offers, particularly with regard to the new Phaser system in MA3. In MA, via MATricks, I have blocks, groups, a fast way to set effect offset instead of spinning an encoder (hit the encoder and type on a ten-keypad), a library of actually useful pre-built effects for getting things up and running quickly, editing effects live while running on stage, and other things that Hog has been slow to implement. We only got flying faders on Hog 4, ten years after grandMA 1 had them.

All of the youngest programmers I know couldn’t give a crap about WholeHog, and with good reason. grandMA is customizable and programming on it gives you a lot of feedback on the command line, if you want to know how something could be automated. Now, some of them want to learn MA not because they have any desire to be cool programmers, but because they want to make a sweet-ass layout view like Christian Jackson invented and do awesome color sweeps. I don’t really see that as a problem, though, because what they’re really doing is learning an (admittedly very high-level) programming language, and they’re getting really good at it. This is, I think, what attracts young people to the grandMA system: it feels more like programming a computer than WholeHog does, and that’s something that more and more young people are comfortable doing at a younger and younger age. Hell, Lua scripts run natively on grandMA as of several versions ago, and there are some really cool ways to use that in your console. (I have one that I use, called IntelliVARs, that allows you to do math with variables in the command line, and lets me do some really cool macros.) People who like (not just “are forced to use”, but like) computers generally enjoy having customization options, and they like hacking and they like learning how to use their equipment better by way of doing silly things with it. I once killed time by teaching myself how to write a macro that would create sweeps across fixtures without using MATricks or Wings, by setting aligned dimmer values and using IfOutput. It was hacky and goofy, but it taught me things about how to make the console do things in interesting ways. grandMA 2 is well-designed, intentionally or not, to appeal to the hacker mindset. (There’s also things like low entry cost, despite what some might think, but I won’t touch on those here. I don’t see pricing as a huge deal to either side.)

I would like to see the WholeHog line developed further, and – frankly – to be a little more MA-like. And I realize that some of my criticisms are probably a bit outdated: I’ve only used a WholeHog 4 on a show once, and it was a day of crazy and fast programming, so I didn’t have time to delve into how much the console has advanced, if any. But it certainly felt familiar. Except for the dark mode and the hardware surface, I could have been programming on a Hog III, and I would have had to look hard to spot the difference. But there are things I’m pretty sure I can’t do, that would ease programming considerably. For instance, quick keys to set selection groups. (I always make align keys on MA, because I use them all the time. On Hog, you have to click two buttons to get to the equivalent function.) I can’t have presets for grouping or blocking like in MATricks, a stupendously useful feature that speeds up programming.

And so I am forced to wonder: what market does HES think WholeHog is for? Churches? The house of worship market is not small, and if they want to focus on that, that’s okay. The largest touring productions are pretty locked into grandMA at this point; nobody uses WholeHog on big shows, with few exceptions. I have mixed feelings about this: on the one hand, good for MA for making a console that everybody likes and everybody knows how to program. On the other hand, I’m intrinsically suspicious of any company that gets a monopoly on any part of the market. Healthy competition helps everyone, but Hog hasn’t been providing any real competition to MA since…ever.

Nor, would it seem, do they want to be.

1. Sure, John Q. Freakington was super into Complites but those never caught on in the states. There were also some programmers skilled with Artisan and Virtuoso and later PRG V676, but those are really niche consoles for award shows, post-VL-not-being-in-the-control-business-anymore.

2. This is a feature that GDTF is currently trying to bring into its universal file format.

3. Hog actually did innovate in a few ways: their pixel-mapping feature was, for a while, the best in the industry.