Support multi-branch pixel controllers and abstract downstream pixel topology in GDTF / MVR

[JamesAdvatek]

Is your feature request related to a problem?

Pixel controllers like Advatek PixLite are increasingly common in professional entertainment workflows, but they do not fit neatly into a fixture-centric GDTF model.

These devices are better understood as multi-branch control devices: one hardware unit with multiple independently patched pixel outputs, each with its own addressing, pixel count, protocol, and mapping behaviour.

A typical pixel controller configuration contains strong control metadata, such as:

• output port number
• pixel quantity per output
• If RGB/RGBW pixels aare being used - 8bit or 16bit pixels are connected.
• start universe per output
• start channel per output
• grouping / effective controllable pixel count
• zig zag / serpentine behaviour
• reverse order
• output pixel protocol

To use an Advatek controller config and API structure as an example, it exposes per-output values such as pixCount, startUni, startCh, nullPix, zigZag, group, reverse, colorOrder, and desc, plus global pixel settings such as colorType, inFormat, and pixsSpanUni.

However, this data does not generally contain enough information to describe the attached LED product as a true GTDF fixture, including:

• physical form factor
• dimensions
• pixel spacing
• orientation
• 3D placement

This creates a standards gap. Pixel controllers are:

• not conventional luminaires
• not merely passive infrastructure
• not complete models of the downstream LED installation, since every deployment may differ

As a result, exporters are forced into awkward approximations such as:

• one large custom fixture
• several custom per-output fixtures
• many per-pixel fixtures
• or a generic infrastructure object with limited semantic value

The gap is visible where the current GDTF version has concepts for geometries, DMX modes, inventory/structure/support objects, and protocol sections such as Art-Net and sACN, but no obvious first-class abstraction for controller-managed pixel branches.

Describe the solution you'd like

It would be useful if GDTF / MVR could support a clearer model for multi-branch pixel controllers. There could be a couple of ways to do this.

In practice, that could mean support for:

• One hardware device containing multiple logical output branches

• Per-branch metadata such as:

  • logical pixel count
  • physical pixel count
  • addressing / patching information
  • channel footprint
  • controller-side mapping metadata

• Standardised remapping fields such as:

  • grouping
  • null pixels
  • zig zag
  • reverse order
  • per-output color order
  • split-across-universes behaviour

• a way to mark outputs / branches as abstract or topology-unknown where the physical downstream LED geometry is unresolved.

• Optional topology hints where available, such as dimensions, traversal direction, pitch, spacing, or estimated length

On the MVR side, it would be helpful if exports could cleanly represent:

• The controller device itself
• Its logical output branches (even if this takes the form of multiple individual data only GDTF RGB LED emitters)
• Optional generic downstream pixel instances where needed for patching workflows
• Unresolved downstream geometry where real placement is not known

This would allow exports to stay honest when a controller knows patching and mapping data, but not the actual installed LED form factor.

Describe alternatives you've considered

Current workarounds tend to be:

• Exporting one large custom fixture
• Exporting one fixture per output
• Exporting large numbers of generic per-pixel fixtures inside MVR
• or representing the controller only as a generic infrastructure object

All of these can work in some situations, but none feels like a clean general model for pixel controllers.

Additional context

This seems like a good indication that “controller with multiple mapped pixel branches” is a real and useful abstraction to support more explicitly.

Projects with significant quanties of pixels require multiple pixel controllers on the network. True GDTF/MVR support would significantly reduce human error, by reducing the workload in the visualisation and deployment process.

[petrvanekrobe]

Hello @JamesAdvatek ,

thank you for the feedback. This is more for the discussion in the GDTF Forum. What you are describing is more related to tooling, as the GDTF and MVR spec allows you to build the setup you describe. In this (architectural) case, you can use GDTF and MVR as a language and build the required system from it, you would not use the same path of building a fixture in the GDTF Builder. It is similar to media servers - the "gdtf for export" is often built on the fly.
So, you can already use GDTF and MVR, either work with a partner who does planning, to implement this workflow or you build a tool yourself to cover this end to end use-case. Hope this helps.

[JamesAdvatek]

Hey @petrvanekrobe, Thanks, this helps!

I agree the current GDTF / MVR language contains many of the low-level building blocks already, and that this may not require a completely new end-to-end fixture-builder workflow.

The part I am trying to highlight is slightly narrower: even if the current spec is technically expressive enough, there does not seem to be a clear standardised modelling pattern for multi-branch controllers.

In our case, the controller exposes structured per-output mapping data such as:

• physical pixel count
• start universe/channel
• grouping
• Colour order
  -...and so on

But it doesn't know the real downstream fixture form factor or placement. The practical question is less “can this be encoded somehow?” and more:

Is there a recommended / interoperable way to model a controller with multiple logical pixel branches when downstream then geometry is unresolved? Or does this fall out of the current scope of GDTF/MVR?

At the moment, tool authors seem forced to choose between:

• one large custom fixture
• one fixture per output and no controller representation
• many generic per-pixel fixtures
• or a generic infrastructure-style object

All of those are possible, but they are quite different representations for what is fundamentally the same controller-driven system.

If the answer is that the current spec already supports this well enough, I think it would still be very helpful to have:

• A documented recommended modelling pattern
• Or an example showing how a multi-output pixel controller should be represented in GDTF / MVR
• Especially where physical downstream topology is unknown
• That would go a long way toward reducing vendor-specific approximations between similar device types, even without changing the underlying schema.

We're keen to explore "gdtf for export" and feel this makes the most sense for our application. The media server-style system makes sense, but still doesn't address the points raised above.

Happy to dive into this on the forum if a better place to discuss. Thanks again.