Tracking

Why a value stays on after the cue that set it, and how to stop it.

Tracking controls how attribute values persist between cues when a cue does not explicitly re-state them. Understanding tracking lets you write compact, maintainable cue stacks rather than restating every attribute in every cue.

Tracking operates at the group level wherever you program with groups. A cue stores “Front Wash = blue”, not eight individual fixture values, and the fully tracked state is shown to you as groups. Those group references are only resolved down to individual fixtures at playback time - see Group-level tracking below.

In the GUI

Tracking is a behaviour, not a button - there is no control to click. It governs how the desk resolves cues you build on the Cues tab (see Cues), and you see its effect in the Cue Inspector, which shows a cue’s fully tracked state (the values it inherits from earlier cues, not just what it stores). Store cues with BLOCK to stop tracking through a point.

Equivalent commands: SHOW CUE <n> FULL (fully tracked view) · STORE CUE <n> BLOCK (block tracking).

The three cell states

Every attribute of every group (or fixture), for every cue in the stack, is in one of three states:

State	What it means
Explicit (delta)	This cue directly stores this value. It was in the programmer when `STORE CUE` ran. The cue owns this attribute from here onward.
Tracked	An earlier cue stored an explicit value for this attribute; it persists through cues that do not re-state it. The desk remembers the last-seen explicit value and replays it.
Blocked (restated)	A cue with the `BLOCK` flag restates the current tracked value as an explicit value in the cue. The look is unchanged, but because the value is now explicit, edits to earlier cues can no longer track through this point.

A fourth implicit state is unset - no cue has ever touched this attribute, so the desk leaves it to playback’s lower layers (other cue lists, faders).

How tracking works in practice

Cue 1: RED=100  GREEN=0   BLUE=0    (explicit - all three)
Cue 2: GREEN=80                     (explicit - only green)
Cue 3:                              (no changes at all)
Cue 4: BLUE=50                      (explicit - only blue)

When the desk goes through this sequence:

At	RED	GREEN	BLUE
After cue 1	100 (explicit)	0 (explicit)	0 (explicit)
After cue 2	100 (tracked from cue 1)	80 (explicit)	0 (tracked from cue 1)
After cue 3	100 (tracked)	80 (tracked)	0 (tracked)
After cue 4	100 (tracked)	80 (tracked)	50 (explicit)

Cues 2, 3, and 4 never need to re-state RED, because it tracks forward from cue 1 automatically.

Storing cues - what goes in

STORE CUE captures the current programmer contents as explicit (delta) values. Only what is in the programmer is stored; nothing else changes.

Attributes the programmer does not contain are not stored - they track automatically from whatever the cue stack already had.

Store modes (CONFIG STORE)

Store modes govern what happens to the programmer after storing. What goes into the cue is the same in all three: the true delta versus the tracked state at that cue number.

Mode	Behaviour
`RETAIN` (default)	The programmer stays active after storing, so you can keep building on the look.
`CLEAR`	The programmer is cleared after storing.
`PLAY`	The programmer overlays on top of playback during editing; the cue is played on store, then the programmer is cleared.

CONFIG STORE RETAIN    # keep the programmer after storing
CONFIG STORE CLEAR     # clear the programmer after storing
SHOW CONFIG            # display the current store mode (and other settings)

To store a cue that restates values rather than only the delta, store it with BLOCK (see below).

Group-level tracking

When you select a group and set an attribute, the desk records the value against the group, not against each member fixture. STORE CUE then tracks that group value forward exactly like a fixture value - only the group attributes that changed versus the previous cue are stored.

The benefit is what you see and edit:

The fully tracked (“resolved”) state of a cue is shown as groups, so there is far less to digest than a per-fixture dump.
Editing a cue against a previous one lands on the group you are thinking about.
Because the cue stores a group reference, changing the group’s membership (adding or removing fixtures) automatically updates every cue that uses it - no re-recording required.

Group references are resolved down to individual fixtures only at playback. Resolution precedence:

The most recently set group attribute wins (the later cue tracks over the earlier one).
An explicit fixture value always beats a group value for that fixture within the cue that sets it.

A fixture that belongs to two tracked groups therefore follows whichever group was set most recently, unless you pin it with an explicit fixture value.

Group tracking applies in CONFIG GROUP REFERENCE mode (the default). In CONFIG GROUP ABSOLUTE mode, group programming is expanded to fixture values at store time and tracked per-fixture instead.

The BLOCK flag

STORE CUE <n> BLOCK makes the cue a track blocker. Block is a store-time materialise: at the moment you store, the desk writes the cue’s full tracked state - both the tracked groups and any explicit fixture overrides - into the cue as explicit values. The look on stage is unchanged, but because every value the cue carried is now explicit, edits to earlier cues can no longer track through this point.

Cue 5:  Front Wash = blue, intensity 80     (explicit)
Cue 6:  [BLOCK]  position tweak              (block: cue 6 restates Front Wash =
                                              blue, intensity 80 as explicit
                                              values, plus the new position)
Cue 7:  Front Wash = red                     (explicit)

If you now edit cue 5 to make Front Wash green, cue 6 still shows blue - the block holds the look it captured. Cue 7 is unaffected.

Block is non-destructive: it preserves the look rather than homing untouched attributes. It only captures what was tracked at the time you blocked - if you later add new content to an earlier cue, that new content still tracks through the block (re-block to recapture). There is no separate “unblock”: a block is just the materialised values, so edit or re-store the cue to change it.

STORE CUE 10 "Clean slate" BLOCK

Inspecting tracking state

SHOW CUE

SHOW CUE 5          # list this cue's explicit changes, parts, and block status
SHOW CUE 5 RESOLVED # show the full resolved state: tracked + explicit for every
                    # fixture/attribute the cue covers

SHOW CUE <n> RESOLVED is the most useful diagnostic: it shows exactly what the desk outputs when cue N is active - the combined result of all tracked values up to and including cue N.

LIST CUES

LIST CUES

Shows all cues with their tracking and block flags:

track: yes - this cue tracks forward (default)
track: no - tracking is disabled for this cue (its values do not track into later cues)
block: yes - this cue is a track blocker

INSPECT / WHY

INSPECT FIXTURE 3 CAP red
WHY FIXTURE 3

Shows which cue last set each attribute and from which layer it arrived in the current output frame. Use this live to diagnose why a fixture has an unexpected colour, position, or beam state.

Cue `tracking` vs `block`

These are two independent flags:

tracking (default yes): when yes, the cue’s explicit values track forward into later cues. When no, the cue’s values stop at this cue and do not flow into later ones - they apply while it is the active cue, and later cues that don’t re-state the attribute fall back to whatever was tracking before it rather than seeing the non-tracking cue’s value.
```
STORE CUE 12 "Blackout hit" NOTRACK   # store a cue that does not track forward
CUE 12 TRACK OFF                      # same, on a cue that already exists
CUE 12 TRACK ON                       # back to normal tracking (the default)
```
The flag is persisted in the show file and shown by LIST CUES / SHOW CUE.

Storing the next cue accounts for this: a cue is stored as the delta against what will actually be tracking into it, so anything the programmer holds that only matched the non-tracking cue’s values is written explicitly (it has nothing to track from), while values inherited from before the non-tracking cue are still left to track.
block: applied at store time with STORE CUE <n> BLOCK. The cue materialises its full tracked state as explicit values, which stops incoming tracking from earlier cues while preserving the look.

Common tracking problems

Problem: a fixture has a colour I didn’t intend. Run INSPECT FIXTURE <id> CAP red (or WHY FIXTURE <id>). Look for which cue last set the colour. Update that cue, not the one where you noticed the issue.

Problem: a cue stores values that I don’t want to track. The cue always captures the true programmer delta, whatever the store mode. Remove the unwanted values from the cue with UPDATE CUE <n> REMOVE FIXTURE <ids...> / CUE <n> FIXTURE <id> REMOVE <cap>, or store with NOTRACK if the cue’s values shouldn’t track forward at all.

Problem: changing an early cue sends unexpected changes into later cues. Use SHOW CUE <later-cue> RESOLVED before and after the edit to confirm the tracked state is what you expect. Store a BLOCK cue at the section boundary to materialise the look and isolate the affected region.

Problem: new content I added to an early cue is leaking past a block. A block only captures what was tracked when it was stored. Anything added to an earlier cue afterwards still tracks through it. Re-store the block cue (STORE CUE <n> BLOCK) to recapture the current tracked state.