The grandMA3 1,024-Attribute Limit: Why Your Show File Hits It — and What To Do About It
grandMA3 caps the show file's attribute pool at 1,024 entries, and when you cross the line nothing warns you — things just quietly stop working. Every dirty fixture profile you import spends that budget. Here's how the pool actually works, where the junk comes from, and what genuinely gets slots back.
The pool nobody looks at until it's full
Every parameter name your show file knows about — Dimmer, Pan, ColorRGB_R, and every oddball name a fixture profile dragged in with it — lives in one ordered list: the attribute pool. It has a hard cap of 1,024 entries, and it is per show file.
The first 286 slots are MA's own canonical attributes — the ones drawn orange in the console UI. They are always present, you cannot erase them, and if a show file somehow lacks one, MA puts it back. (Of those 286, 278 are ordinary PascalCase names; eight are intentional all-caps initialisms like CTO, CTB, CIE_X and the XYZ_ axes — so not everything shouty is junk.)
Everything from index 287 up is custom: attribute names introduced by fixture types you loaded. Do the arithmetic and the real number that matters falls out:
- Total cap: 1,024
- Canonical, always present: 286
- Your actual budget for custom attributes: 738
That budget is spent by importing fixture profiles, and on a big rig with profiles from mixed sources it is smaller than it sounds.
What happens at 1,025
Nothing announces itself. There is no error dialog, no red banner. Attribute number 1,025 and beyond simply doesn't function in show usage — the overflow entry sits in the pool, silently broken.
A real-world example from a large broadcast show file: the pool sat at 1,025 / 1,024 — one over. The overflow was an entry literally named Attribute with an empty feature group, dead in the pool with nothing on the surface telling anyone. That is the failure mode: not a crash, but a parameter somewhere in your rig that will not behave, on a show where you have a hundred more urgent things to chase.
That's also why the goal is not a pristine pool. A show file sitting at 700–800 attributes is healthy. The goal is headroom — enough slack that patching one more visiting artist's mystery fixture on load-in day doesn't tip you over the silent cliff.
Where the junk comes from
Almost all of it arrives the same way: importing fixture profiles. Every custom attribute name inside a profile is added to the pool when the fixture type comes into the show. The worst offenders, in rough order:
- MA2-converted profiles. Fixtures that came through a grandMA2 conversion carry ALL-CAPS attribute names like
FIXTURESHUTDOWNandCONTROLRANGESELECT— names that duplicate canonical attributes in meaning but not in spelling, so each one burns a fresh slot. - Vendor-built and downloaded profiles. Manufacturers and profile-sharing sites invent their own PascalCase names rather than mapping to MA's canonical set.
- Generic and hand-built profiles. These tend to introduce space-separated, free-form names that match nothing.
The per-fixture tax is real: a dirty profile commonly drags in 10–20 non-standard attribute names on its own. On one real 194-fixture show, the file had 864 declared attributes, of which 361 were non-standard and 302 were orphans — custom attributes referenced by exactly one fixture type each. On the 1,025-attribute show mentioned above, 426 distinct ALL-CAPS names sat in the pool, 146 of them single-fixture orphans.
An orphan — a custom attribute used by exactly one fixture — is the signature of a sloppy profile. A custom attribute shared by several fixture types is at least earning its slot; an orphan exists because one profile author didn't check what the console already had.
How to see where you stand
The pool is inspectable on the console. The attribute definitions live in the patch data, and the list is ordered — canonical entries (orange) first, then everything your imports added. For scripting types, the pool is exposed to Lua under Patch().AttributeDefinitions, which makes it possible to dump and count the entries rather than eyeballing a long list.
What you want to know is three numbers: total entries (distance to 1,024), how many are custom (distance to the 738 budget), and how many of the customs are orphans (your junk-density indicator). If the total is north of ~950 on a show that still has fixtures left to patch, treat it as a load-in problem now, not a maybe-later problem.
What actually frees slots (and what doesn't)
The intuitive fix — rename the ugly attributes to sensible ones — mostly doesn't work, and it's worth understanding why before you spend an afternoon on it.
- Renaming a custom attribute to a canonical target can free a slot. The canonical was already in the pool, so the custom gets collected. This is the one rename that pays.
- Renaming to any non-canonical target doesn't necessarily free anything. You may just trade one custom entry for another and end the day at the same count.
- Canonical ghosts can't be removed at all. Even if no fixture references a canonical attribute, MA reinjects it on every show. Those 286 slots are gone forever; make peace with it.
And the empirical punchline, from working an over-cap show file by hand: of 297 orphan attributes examined, only 4 could be safely auto-merged onto existing names. Renaming is not a cleanup strategy; it's a rounding error.
What does move the number:
- Prune modes you'll never use. Many imported fixture types carry every DMX mode the product has ever shipped, and the modes you don't patch still contribute their attribute baggage. Cutting a profile down to the mode(s) you actually run is where real relief comes from.
- Rebuild the worst fixtures. A profile that brings 15–20 orphan attributes for a light that is functionally a dimmer, a color mixer, and a strobe is a candidate for rebuilding against MA's canonical attribute set. One rebuilt profile can return a dozen slots.
- Vet before you import. The cheapest slot is the one never spent. Import an unknown profile into a scratch show first, look at what it adds, and only then bring it into the real file. Once a dirty profile's attributes are in a show that has history in it, getting them out is the hard direction.
Where VLA fits
VLA's Fixture Tools do the accounting for you. The app reads your show's fixture types and attribute pool and states where you stand against the 1,024 cap plainly — every custom attribute listed with what's using it, so shared customs and single-fixture orphans stop being invisible. Per fixture type, VLA resolves each DMX mode into a true channel map (including pixels that MA hides inside geometry references) and flags each channel's attribute health, so you can see what a profile will cost the pool before it goes anywhere near the console. It's the difference between discovering the cap at 1,025 and never getting there.