DMX POPs - inconsistencies [2025.30280+30770]

Hi everyone,

Not sure if I should’ve created a new topic or added this to an existing one - some of these points may have already been mentioned elsewhere - so here it is.

I’ve been migrating our pixel mapping workflows to POPs for obvious reasons (convenience and performance - won’t be missing the Shuffle CHOP anytime soon), but I’ve noticed several inconsistencies or unexpected behaviors. After scratching my head for a couple of days, I’m guessing it’s probably something I’m just not seeing.

I’ve attached a file that showcases the issues. Some of them aren’t visible unless you have the actual hardware, but I’ll try to explain (Richard Burns can confirm - he was visiting our studio with his lovely family while I was working on this ).


DMX Out:

  • Active Toggle On/Off - At least with our hardware setup, once the Active toggle is turned off, it can’t be turned back on unless you restart TouchDesigner. At least our controller doesn’t respond well

  • [POP Copy Bug (DMXFixtureNetAddress)]:
    I discovered a small bug while working with DMXFixtureNetAddress.
    Not sure if this is expected behavior, but when copying the attribute (in my case, DMXFixtureNetAddress as a uint[4]) from point to priimitive, the default value isn’t carried over.
    However, if the same attribute is created on the source POP and then copied to the primitive, the value is transferred correctly.

  • ArtSync - for some reason, the signal becomes really juggy with ArtSync turned on, which si the opposite of the smooth. Just wondering if it wasn’t inverted or our equipment. Tested on 2 controllers.


Layout / AutoLayout:

Could we get more detailed documentation or explanation on how Layout and AutoLayout work within DMX Fixtures?
My assumption was that layout is based on primitive index and then point order within the primitive, but maybe I’m missing something.

In most of my tests, I don’t see a difference between AutoLayout on or off.

Here’s a concrete example from the file:
We have custom-built volumetric LEDs in a 10x10 matrix, but the controller only has 8 ports, each handling 6 universes.
As a result, the last two rows of the matrix are split into 4 parts, and half of each is added to the first 4 ports (e.g., Port 1 has one full row (#1) + half of row #9, etc.).

With the new POP workflow, the most straightforward way is to use DMXFixtureUniverseOffset to manage port assignments.
I assumed that with the same offset (e.g., 0), AutoLayout would arrange the data in sequence - first row, then continue with the split part of the last row in proper increment order.
But this doesn’t seem to be the case - the layout results are unpredictable.

I also tried manually setting the correct primitive order alongside DMXFixtureUniverseOffset, but got similarly inconsistent results.
So - is this a WIP, a merging issue, or an undocumented behavior?


In the same file, I included two pixel mappers using the same controller.
One (linear mapping) works fine—aside from the Copy POP issue which can be worked around.
The other (voxel mapping) does not work.

Any insights would be greatly appreciated.

Thanks and sorry for the long post!

Cheers,
sH


Let me know if you’d like a more formal version or a shorter TL;DR version.

DMX Pop - pixel and voxel mapping.toe (17.5 KB)

1 Like

Hi again,

Couple more issues detected on further testing:

DMXFixtureNetAddress

  • this is amazing feature to be able to actually give the address of the controller and not flood the network. But for now, DMX Fixture POP sees it all, but DMX OUT POP doesn’t. See below

a small question: when using DMXFixtureNetAddress, what’s the politics of the parameter netaddress on DMX POP Out? Empty, 255.255.255.255? How the local address is handled and how far we can push it? With multiple Gbe cards/outputs, can we send on say 2.0.0.8 and 192.168.1.10 from the same DMX Out?

thnx
sH

  • Active Toggle On/Off - At least with our hardware setup, once the Active toggle is turned off, it can’t be turned back on unless you restart TouchDesigner. At least our controller doesn’t respond well

Could you elaborate a bit more on this? What exactly is going wrong, is it just that it’s not sending any packets, or something else?

  • [POP Copy Bug (DMXFixtureNetAddress)]:

We’ll take a look into this.

  • ArtSync - for some reason, the signal becomes really juggy with ArtSync turned on, which si the opposite of the smooth. Just wondering if it wasn’t inverted or our equipment. Tested on 2 controllers.

Yeah, ArtSync is broken on the DMX Out POP in the experimental builds, but it’ll be fixed in the next experimental build we release: 2025.30330+.

Could we get more detailed documentation or explanation on how Layout and AutoLayout work within DMX Fixtures?

You’re correct that Auto Layout iterates over the DMX Profile page in primitive then point order, incrementing the channels and universe as it goes, starting from the parameter values. I’ll also add that by using the DMXFixture* attributes you are overriding some of the auto layout’s capabilities, so it becomes less of an auto layout mode, in that sense. For example, DMXFixtureUniverse will manually override the starting universe for each primitive and it won’t be wholly determined by the auto-incrementing global universe value.

I think the confusion arises because when the routing table is missing or has no entries, it defaults to Auto Layout. I’ll add some warnings to these cases so it’s a bit clearer as to what’s happening.

Also, one thing I noticed in the attached file is that you are using a Math Combine POP as the input to your DMX Out POP. The DMX Out POP is a bit of a special case when it comes to wired inputs in that its inputs must always directly be DMX Fixture POPs.

a small question: when using DMXFixtureNetAddress, what’s the politics of the parameter netaddress on DMX POP Out? Empty, 255.255.255.255? How the local address is handled and how far we can push it? With multiple Gbe cards/outputs, can we send on say 2.0.0.8 and 192.168.1.10 from the same DMX Out?

The order of precedence of netaddress values is the following: netaddress from the DMX Fixture POP (either from DMXFixtureNetAddress or the routing table netaddress column), netaddress from the DMX Out POP routing table column, and finally the netaddress parameter on the DMX Out POP. If all the input DMX Fixture POPs are using the DMXFixtureNetAddress attribute then it really doesn’t matter what you set the netaddress parameter to, but you can think of it as a fallback value in the event one of the input DMX Fixture POP’s is not using the attribute, so you could set it to some desired default value, or leave it blank (which means they will not be sent).

Note: the exception to this is when using sACN and multicast, in which case the DMX Out POP will overwrite the specified address with the appropriate multicast netaddress.

Currently, the local address can only be specified using the parameter on the DMX Out POP, so it’s not possible to send from two different network interfaces from the same DMX Out POP. But I think it would be a good idea to add a localaddress/srcaddress column to the routing tables, as well as a new attribute.

Regarding this issue: could you attach a small example? I believe it is already fixed but I just want to confirm with your specific case.

Hi Eric,

  • Active Toggle On/Off - At least with our hardware setup, once the Active toggle is turned off, it can’t be turned back on unless you restart TouchDesigner. At least our controller doesn’t respond well.

Could you elaborate a bit more on this? What exactly is going wrong, is it just that it’s not sending any packets, or something else?

Yes, it’s pretty much that - it’s not sending any data after couple of on/off.

  • [POP Copy Bug (DMXFixtureNetAddress)]:

We’ll take a look into this.

Thank you! It is consistent, by the way. Just did another patch - same thing.

Yeah, ArtSync is broken on the DMX Out POP in the experimental builds, but it’ll be fixed in the next experimental build we release: 2025.30330+.

Glad it’s already addressed.

Also, one thing I noticed in the attached file is that you are using a Math Combine POP as the input to your DMX Out POP. The DMX Out POP is a bit of a special case when it comes to wired inputs in that its inputs must always directly be DMX Fixture POPs.

Ok, good to know, please mention it somewhere in documentation. I put Math Combine just to ‘extract’ the inherent order with _PrimI and to display it in Chop as there’s no other way to check the order. Btw, the issue I show isn’t affected by this as it is apparent already on the DMX Fixture POP.

You’re correct that Auto Layout iterates…

Thanks for explanation (useful for documentation). I would think so either, sounds logical, and yet, in my ‘non-working’ example, it’s not behaving. Funny, while typing I actually got the solution of my non-working example :slight_smile: Auto-Layout name made me think it’s more intelligent than it is. I was addressing all my strings with the same DMXFixtureUniverse thinking that Autolayout will kind of ‘group’ them together and will lay out them out automatically. But it doesn’t do that as DMXFixtureUniverse overrides it all. Got it!

The order of precedence of netaddress…

Thank you. I thought as much, but it’s great to have the confirmation for future references. Localaddress thing would minor but pleasant addition to already feature packed POPs, but we work in realtime, so if everything can be done in one go, looks like an easy win.

Thanks again,
Cheers
sh

Hi @_shandor

regarding the Copy POP and the Template Attributes:

This is something I stumbled across myself but have to get used to: The default value you specify for the Point Attribute on the Line POP is only used in the parameters for the individual points when creating new points.
In your example when looking at the Line POP, the 2 Points have their DMXFixtureNetAddress parameter set to 0 0 0 1 respectively.
The extra point created via the setting in Divisions would also only interpolate between the attribute values of the 2 defined anchor points.

regarding the mapping of the 10x10 matrix:
For the correct mapping, my current suggestion would be to create Linestrips that cover a whole universe. So there would be a Linestrip that includes row1 plus the first half of row9.

Still checking though your file… will answer a bit more.

cheers
Markus

Hi Markus,

Thank you for clarification. I included 2 examples that you can switch - one work, on doesn’t: setting the prim attribute doesn’t work, Copy POP doesn’t copy the default value, which is a pitty as this is Prim only attribute that’s taken into account by DMX Fixture. I think it would be cleaner solution than then use attribute conversion.

Regarding the matrix, it’s a great idea. I was thinking visually which is non-sense, I needed to think data!

In general, I think cleaner solution proabably would be the advanced/mixed use of Auto-Layout as I thought it would function: it would kind of “group” primitives with the same DMXFixtureUniverse and instead of write it over the previous one, it writes sequencially and just continue’ to layout primitives one after another with the same DMXFixtureUniverse. It’s another level of checking for auto-layout, but cleaner for multiport controllers and big installs. Probably it is more logically “heavy” though.

cheers Markus,
I see the path how to make it work
sh

Hi Eric,

Yes. This is the exact example from the screenshot.
DMXFixtureNetAddress_bug_0.1.1.toe (7.2 KB)

Cheers
sh

Thanks for the file. I can confirm that this will indeed be fixed in the next experimental build we release: 2025.30500+.

The active toggle/sending bug on the DMX Out POP will also be fixed in the next experimental build we release.

As for the auto layout, I do agree that it could be more sophisticated in how it increments through channels when overriding using attributes. It does increment independently when using separate DMXFixtureNetAddress values, but when specifying DMXFixtureUniverse it instead resets the channel counter to 1. We’ll discuss internally how we can make further improvements to this.

Thank you, Eric. Sounds wonderful and looking eagerly forward to updates.

Cheers,
sh

Hello Guys,

Thank you so much for fixing lots of stuff in DMX Pop and DMX Out! Network address works like a charm now and multiplier is very handy.

I still have no luck though merging universes with DMXUniverseOffset in a more complicated configuration.

Probably I don’t see smth and/or it’s a feature and I’ll be happy to learn smth. I created a real world example for that.

Basically, when merging on DMX Fixture POP in my case data don’t make any sense now. But if I use DMX Out and manually add 2 different DMX Fixture POPs with separated primitives (linestrips=ports), it works as it should, as if DMX Fixture somehow messes the primitive ids and multiplying by some random number. It only happens with AutoLayout. Using routing table the old way, works as expected, at least according to DMX Map.

I included example of multiple modules - with new method (autolayout) the count goes to 27085 universe (!), but doing basically the same thing the old way with routing table I’m happy to say I have the correct 573 max universe.

I annotated lightly and color-coded the example for quicker understanding.

If I’m bound to use routing table, so be it, though it will be really hard to understand and debug with the real equipment when it’s working and when it doesn’t.

Thanks for your amazing job
sh

DMX Pop - pixel and voxel mapping v2.24.toe (15.1 KB)

Thanks for the example. It looks like there’s a bug in 2023.30770 with incrementing universe/channel values when the DMXFixtureUniverse attribute value is greater than 15. I’ve fixed the bug and here is a build with the hotfix:

Please let me know how that works for you.

1 Like

Hi Eric,

Thank you so much for taking time doing this and special build and all. It’s like Christmas came earlier this year. It does work as it should and I’m so happy not having to use a routing table anymore!

Cheers! :banana:
sH

1 Like