Proposal: mandatory DMXModeID for GDTF DMXMode and dmxModeID for MVR …

[kinglevel]

Adds a new proposal under spec/proposal/dmx-mode-uuid/ describing a coordinated GDTF + MVR major-version change that introduces a mandatory portable UUID on and a matching required UUID attribute on the MVR-side reference.

Today mode identity reduces to (FixtureType-GUID, mode-name-string) — brittle to renames, reorders, exporter quirks, and GDTF-revision drift. The proposal closes the gap so patching/fixture-swap/MVR-update flows can rely on stable mode identity instead of name+index heuristics.

[petrvanekrobe]

Thank you for the PR and thinking about it. If a DMX Mode was to be marked with a UUID, there would need to be a lock is some kind of external database and if the manufacturer has changed the data, all files would need to be rewritten. For GDTF UUIDs, the GDTF Share is the arbiter of the IDs, it also keeps the linking of the UUID-Name and Manufacturer. There is no such concept for DMX Modes, the only first class ID coming directly from the device, which we could utilize for this would be the DMXPersonality, and only for devices which support RDM. I would tend to think that this is up to the proper naming by the manufacturer when creating the files and up to the tooling to correctly use this data with care, the same way other GDTF data should be treated.

[kinglevel]

Thanks, that makes sense.

I think the proposal should be clearer that this is not meant to be a centrally issued or registry-locked ID. The ID would be generated when the DMX mode is created, and then preserved by tools across non-semantic changes such as renames, reordering, exporter changes, or metadata cleanup.

The main reason I think this is needed is that names, indexes, and personality numbers are not reliable enough as identity keys in real-world files. Users and tools often create, rename, adapt, duplicate, or reorder DMX modes, and not all of that comes directly from the physical device or from RDM. In practice, many personalities are created or modified in fixture builders, visualizers, converters, and user libraries.

So the goal is to give GDTF/MVR a stable way to cross-find the same DMX mode without relying on string matching or integer positions.

A concrete example: if Astera added a new Titan Tube mode in the middle of the mode table, all modes below it would shift if tools identify them by index. That could break references to many existing modes. A stable mode UUID would avoid that.

I also see the issue where users copy old GDTF fixtures and modify them, creating accidental duplicates or near-duplicates. A strict copy/regenerate-token rule could help here: preserving IDs when the same mode is intentionally carried forward, but generating new IDs when a copied mode becomes a different semantic mode.

I do not have deep experience with every detail here, at all, so this is mainly feedback from a advanced operator perspective with tooling knowledge. Tols that need to find the correct modes quickly and precisely, a stable DMX mode identity would make this much more robust than today’s string/index matching.