What is GDTF — and why do fixture profiles need a standard?

Every major lighting console has fixture profiles. That sounds like a solved problem right up until a show moves between tools.

Prepare a rig around a grandMA3, then arrive somewhere with a Hog and an operator who can actually use it. The lamps have not changed. Their DMX modes have not changed either. But the description each piece of software uses to understand those lamps may be completely different.

Historically, every console and visualisation ecosystem had its own answer to fixture data. Manufacturers supplied libraries, software vendors maintained their own libraries, users built missing profiles, and everybody got very good at moving the same information around in slightly different shapes.

GDTF — the General Device Type Format — is an attempt to make that part boring.

The problem is bigger than channel 1 = dimmer

A modern fixture profile needs to describe considerably more than a list of DMX channels. Even a fairly ordinary moving light can have several DMX modes, 16-bit parameters, colour systems, gobos, prisms, shutters, zoom, focus and movement behaviour. A visualiser also needs to know what the fixture looks like and which parts move.

That is where proprietary fixture libraries become awkward. The same physical device may be represented separately in a console, a CAD package and a visualiser. If one definition is wrong or incomplete, fixing it in one tool does not magically fix the others.

GDTF provides a shared machine-readable description instead. The current published specification is GDTF 1.2, described by DIN SPEC 15800:2022-02.

What does a GDTF file actually describe?

At a practical level, a GDTF fixture can contain the information different parts of the workflow need to agree on the device.

• DMX modes and channel functions — what is controlled, on which channel and with which ranges.

• Physical geometry — including a hierarchy of parts such as base, yoke and head rather than one anonymous 3D lump.

• Movement and physical properties — for example pan and tilt ranges and other data software can use to model behaviour.

• Optical and visual data — such as beams, colour information, gobos and related resources where the profile provides them.

• Metadata and identifiers — enough information to identify the device and its definition consistently across tools.

The important bit is not that every application must use every field. A lighting console, a visualiser and a planning tool care about different parts of the same fixture. GDTF gives them one place to get that information from.

One fixture can still have several personalities

GDTF does not remove DMX modes, because the fixture itself has not removed them. A profile can describe multiple modes for the same device, and choosing the correct one still matters.

A 16-channel mode and a 32-channel extended mode may belong to the same lamp, but they are not interchangeable in a patch. Channel numbers move, functions appear or disappear, and a perfectly good profile used with the wrong mode can produce results that are wrong without producing a useful error.

That deserves its own explanation, so there is a separate article on reading and choosing GDTF modes rather than turning this one into a DMX-table endurance test.

Where do GDTF profiles come from?

GDTF-Share is the public library around the format. Manufacturers can publish device definitions there, and users and software can search for profiles. A growing number of manufacturers publish official profiles themselves.

That distinction matters. A shared format does not guarantee that every file in existence is equally complete or correct. Manufacturer-provided data is preferable where it is available, and real software still needs to cope with profiles that contain less information than the ideal example in a specification.

In other words: standardised does not mean reality has suddenly become tidy.

GDTF is not MVR

The two formats are often mentioned together because they solve adjacent problems, but they are not the same thing.

GDTF describes a device type: what a fixture is, how it is built and how it can be controlled. MVR describes a scene: which fixtures and other objects are in a project, where they are, how they are patched and how the scene moves between applications.

A useful shorthand is: GDTF describes the fixture; MVR carries the rig. It is deliberately a simplification, but it is a much better place to start than treating both as mysterious files exported by Vectorworks.

Why this matters in an actual workflow

The boring version of interoperability is the useful version.

Draw a fixture once. Use the same device definition when you patch it. Let the visualiser understand the same channels. Move the project to another tool without somebody spending the afternoon rebuilding profiles because one vendor calls an attribute something slightly different.

GDTF does not guarantee that every application interprets every detail identically, and it does not make bad data good. What it does provide is a common description that tools can implement instead of each maintaining another isolated fixture language.

How FlexViz uses GDTF

FlexViz uses GDTF for the same reason other lighting tools do: if a fixture already has a machine-readable description of its modes, geometry and DMX behaviour, drawing that information again would be rather pointless.

From the patch, FlexViz can search GDTF-Share by manufacturer or model and let you choose the DMX mode that is actually patched on the desk. The profile is then used by the scene instead of inventing another FlexViz-specific fixture definition.

That is the product-specific bit. The more important point is the one GDTF started with: the fixture should not need a new identity every time it crosses an application boundary.