DMX Fixture POP - behavior differences based on input primitive

When I create a set of points for the DMX fixture POP to parse using the Point and Copy POPs, it seems to swizzle the channels perfectly in the way that I would think they should

however, when i switch the input to a set of 3 points that I generated from a line (even going through the primitive POP to just keep the points), it seems to reorder the channels in a way that I don’t like, that breaks the DMX out POP when i send the data to fixtures.

My question: is this intended functionality? I don’t understand as I used PopTo DAT’s to verify that both input POPs are identical in their collections of points.

Using the first stable TD with POPs 2025.31500

Here’s a test file that shows the behavior, toggling the “origin” parameter on the tox will show the reordering

dmx_fixture_tst.tox (3.5 KB)

It is intended, and it is do with the way channel construction works.

The DMX Profile is applied exactly once to each primitive to construct its channels, and each primitive will be laid out one after the other in the universe channel layout, with some channel gap in between them (assuming auto-layout mode). Then, within each primitive each point is iterated over in order whenever there is a DMX Channel sequence block assigned to Point mode.

There is some nuance here with how DMX Channel sequence blocks are laid out in the channels. All components that are together in a DMX Channel sequence block will have their components interleaved in the channel output. Subsequent DMX Channel sequence blocks will not be interleaved together (and instead will come entirely after the previous block in the channel output) unless explicitly enabled to do so with Merge with Above Block.

One more bit of context: when there is a collection of points in a POP that has no primitives, they are considered to be all a part of one primitive, as far as the DMX Fixture POP is concerned.

To apply this to your example:

copy1 has 3 points and 3 Point Primitives, meaning each point is considered distinct from one another when the DMX Profile is applied because they are their own primitive, and therefore they will be constructed right after one another. Within each primitive, each of the DMX Channel sequence blocks are applied, none of them are merged or interleaved, but it doesn’t matter anyway because each Point Primitive only has one point.

primitive1 has 3 points and no primitives, so they’re actually all considered as part of the same primitive according to the DMX Fixture POP. So, the DMX Profile will only be applied once. What you’ll notice is that all of your DMX Channel Sequence blocks for each type are separate, which means they won’t be interleaved together so they will be applied one at a time for every point in order. That’s why you get each DMX Channel sequence all at once in your output. The solution here is to enable Merge with Above Block on your blocks to ensure they’re interleaved, or more simply, you can specify any number of attributes in the Attribute parameter and they will all be interleaved together: eg. “dimmer c”.

However, one missing bit of functionality is the ability to merge constant and attribute blocks together. I’ll make an RFE for that, but in the meantime you can work around it by adding white_amber_uv, stobe, fx, and fx_speed as attributes on the input.

TLDR: use Merge with Above Block to interleave point channels together, or combine them directly by putting all the attribute values together in the Attribute parameter (eg. “P Color N”).

I understand! Thank you for the clarification, in looking through the OP Snippets it’s starting to make more sense why this way of shuffling channels was chosen. Good to know about the “Merge with Above Block” parameter.

1 Like