Skip to content

Macros

The problem

The breakdown starts. You want the bar chaser off, the beams off, the movement effect stopped and one wash sitting low in deep blue, so the room falls into darkness in one move. On the console that's four or five actions on two pages, in the dark, with one eye on the DJ. You'll get three of them right, and the fourth one late.

The same thing happens away from the show. Before doors open you check the same list every night: Blind off, Highlight off, the grand master up, the world back to full, every executor off. While programming you type Store Cue … Fade 5 fifty times. Each of these is a fixed list of commands you already know, and you're the slow, error-prone part of running it.

The idea: a pool object full of command lines

A macro is a list of command lines stored as an object in the Macro pool. Running it sends the lines to the console one after the other, as if you had typed them. Because grandMA2 is driven by its command line, the manual's rule is simple: if something can be done from the command line, a macro can do it. Learning macros mostly means learning the command line; the Command Line Feedback window shows the command behind almost every key press, and marks lines that came from a macro with the macro and line number.

The breakdown from above becomes one macro, Breakdown:

No. CMD Wait
1 Off Executor 1.5 Thru 1.7 Follow
2 Go Executor 1.3 Follow
3 Fader 1.3 At 30 Follow

Executors 1.5 to 1.7 are the bar chaser, the beams and the movement effect; 1.3 is the wash look in deep blue. The macro holds no light values of its own: it plays executors that do. That's the normal split. Looks live in presets and sequences, and a macro only moves the handles. The Fader line has the same catch as on Getting back to the baseline: a physical fader without a motor won't follow it.

Where a macro can run from

  • The pool: tap it, or Macro 5 Please, or type Macro 5.
  • A key: an executor, an X-key or a view button (Assign Macro 1 At Exec 2.7). The difference matters: macros on executors are part of the show and shared by all users, while macros on view buttons and X-keys as view buttons belong to the user profile.
  • Other commands: anything that runs commands can call Macro 12: a cue's CMD column, a chaser step, a timecode show, a remote input. That makes macros the reusable building block; see Timecode shows for how they compare with cue lists and chasers as routines.

Lines run fast, unless you say otherwise

Each line has a Wait column, used when the macro's Timing is on:

  • Follow: go to the next line at once (the default).
  • A time in seconds: wait before the next line.
  • Go: halt here until the macro gets the next Go.

The manual calls wrong timing "the major pitfall". The console is multitasking, so a line can start before the previous one has finished. Its example: Channel 10 At 50 followed by Park Channel 10 parks the channel before it reaches 50%; a wait of 0.05 s on line 1 fixes it. A command that works when typed but not in a macro is the typical sign. The manual's advice is to start with 0.1 s per line and speed up afterwards, and to expect a session with several stations to need more time than a standalone onPC.

The Go wait turns one macro into a toggle. The manual's example switches sACN on, relabels itself and recolours its frame, then halts on Go; the next press runs the second half, which switches sACN off and relabels it back. One button, two states, and the label always says what the next press does. Top restarts a macro from line 1, GoBack runs the previous line, and Pause holds a timed macro.

To verify in onPC: check 27

Recording instead of writing

Record Macro 5 (MA + Store, then Macro 5) records what you do until the next Record Macro. Only commands that show up in the Command Line Feedback get in, with the time between them, so the result is a timed macro: it replays at the speed you worked. Fader moves and screen taps that don't produce a command are not recorded. Recording is a good way to get the commands right; editing the result (shorter waits, an Info text per line) makes it a macro you can still read in a month.

Macros that work with the command line

Normally every line ends with an invisible Please. The @ character changes that:

  • A line ending in @ puts its command in the command line and waits for you to finish it: Group 4 At @ waits for a value, then the next line (Store Cue) runs.
  • A line starting with @ appends to what you have already typed. @ Fade 5 on a key turns Store Cue 5 plus that key into Store Cue 5 Fade 5.
  • @ on both sides only types the command, which gives you a key for a keyword that has none (@ Layout @).

The second and third kind need the macro's CLI (command line interaction) turned off. With CLI on, tapping a macro also takes part in the command line like any pool object (so Edit + tap edits it); with CLI off, a tap only runs it, and Edit Macro 5 has to be typed.

Kinds of show macros

Practice

Most useful macros fall into a few kinds. Knowing which kind you're building tells you which timing it needs and where it belongs.

Kind Example Timing Where it lives
Moment Breakdown, Prepare drop: executors off and on, a fader set Follow, or 0.1 s where lines depend on each other executor button on the busking page
Reset Home, Baseline: programmer cleared, main page, defaults back Follow, small waits fixed executor, same place on every page
Toggle effects on/off, sACN on/off, a second look armed Go halt between the halves executor button; the label shows the state
Command helper @ Fade 5, At + 5, Preset Live Fade none, CLI off view button or X-key in your user profile
Setup Show running status: Blind, Highlight, Solo off, executors off, world 1, grand master 100 Follow the pool; run once before doors

The Home macro is described on A forgiving show, the Baseline macro on Getting back to the baseline. The Show running status list is from the manual's examples and is a good starting point to extend with your own default executors.

Practice

  • Name and colour every macro, and fill in the Info column for anything longer than three lines. In the dark, the label is all you see.
  • Few show macros. Five well-tested buttons beat twenty you have to think about. A macro you haven't tested in the current show file is a guess.
  • Test with the real show running. Test Macro in the editor runs every command for real; it isn't a simulation. Test lines one at a time with Test Line, and disable lines (the Disable column) instead of deleting them while you try things out.
  • Refer to executors, not to values. Go Executor 1.3 survives a reworked wash look; a macro full of Fixture 1 Thru 4 At 30 has to be rewritten when the rig changes.

Macros that ask, remember and decide

Three features make macros behave like small programs:

  • Pop-ups: text in parentheses asks the user and is replaced by the answer. Replace Fixture (old Fixture?) With Fixture (New Fixture?) asks twice, then runs. Quotes inside the parentheses (("Name?")) make the answer text, for variables; without quotes it's read as a number or command.
  • Variables: SetVar $chorus = "Executor 201 + 204 + 205" stores text that later commands reuse (Go $chorus). SetVar variables are global, SetUserVar ones belong to the current user, AddVar adds numbers or appends text. The console keeps predefined ones up to date, such as $FADERPAGE, $SELECTEDEXEC and $SHOWFILE. Names aren't case sensitive.
  • Conditions: a line starting with [$answer=="yes"] runs only if the comparison is true. The manual warns that values are compared as text, character by character: "61" counts as greater than "599".

The manual's SaveShow Enumerate example uses all of it: a counter variable, text appended to a base name, and a line that disables the macro's own first two lines after the first run.

Interpretation

Pop-ups, variables and conditions are mostly programming and setup tools. During a busked set, a macro that stops to ask a question is a macro you shouldn't press. Keep show macros to fixed lists that finish on their own, or toggles that halt on Go.

Beyond macros

For logic that gets unwieldy as command lines, grandMA2 has Lua plugins, which the manual calls "for the very advanced users"; see How the hardware shapes the show. MA also ships predefined macros (Load Predefined in the editor, or an import): small ready-made tools, and the manual recommends them as a way to learn how macros are written.

When you need it, and when not

  • Busking: two or three moment macros and one reset macro on fixed buttons cover most of what a small rave rig needs. Build them once the executor layout has settled, since they refer to executor numbers.
  • Programming: command helpers on X-keys or view buttons save time on every cue. Record a macro the first time you notice you're typing the same sequence again.
  • Setup: a start-of-show macro is worth it as soon as you play the same show file more than once.
  • Skip at first: pop-ups, variables and conditions (Macros that ask, remember and decide) and Lua plugins, until a concrete task needs them. A small hobby rig rarely does during the show.

Sources