FIXED: DMX POP not smooth output version 2025.32820

dear derivative,

i finaly came around to rebuild my dmx system using the dmx pops. the fixture pop is amazing! really convenient how to control different kind of fixtures in 3d space. but i started to notice that the output was doing some weird things.

  • my file runs at 60 fps but my output only funs 55-56 fps (what I can see with artnetominator)
  • also the output is not really smooth

i checked it with with using dmx out chop to compare the results. i made a file that only puts a sinus on the red channel. and outputs the dmx both via the dmx pop and the chop.
this is the smooth result that comes from the dmx chop:

and this is the more jagged result from the dmx pop:

here is the file that i used to test this behaviour. i tested this both using artsync on and off and the result is the same.

dmx pop test.toe (4.5 KB)

thanks in advance!

Thanks for the example - I’m able to reproduce with that.

As an aside, you can also verify the send rate by using the DMX Out POP/CHOP’s Info DAT, specifically the packet_rate field. There, I can also see that it tops out at a rate of only about 57.

I will look into this further and update you once I have a fix.

Can also reproduce this. Maybe interesting to note that it always caps at a slightly lower rate than requested. So when I set the project to 50fps this caps at 47 ish.

Output smoothness is improved in the latest official version: 2025.33070. The discrepancy between the packet_rate and the rate specified on the parameter is also fixed.

thankyou very much!!

Hi Eric,

i’m working on quite a big project now and i have to send out 55 universes of artnet to an MA3.

i did this amount of universes before and never had issues with it, but now my output keeps dropping packets (less then before so that is nice), but still too much that the MA3 can’t handle it and the outputs is really jagged. i first tried sending it out with a dmx pop, and then with a dmx chop, but both have a jagged output.

my sollution for now is a touch out to another instance of touchdesigner running on 2023.12600. that version outputs the artnet perfectly.

i made videos in our pre-programming studio that shows the difference between the 2023 output and the 2025 one, but unfortunatly i can’t share those videos on this forum because of the nature of that project. I can however send them to you privately if that helps?

here is the artnetominator view of the 2023 version:

dmx out test 2023.toe (4.0 KB)

and here is the artnetominator view of the 2025 build:

dmx out test 2025.toe (3.9 KB)

also interesting to note, the sACN output seems smooth! but the MA3 caps that input at 20 universes, so unfortunatly we can’t use that for now.

please let me know if could be of help trouble shooting this issue by providing more examples etc.

thanks in advance!

@Barts.art

I can reproduce the warning on artnetnominator, but not the jaggedness you’ve described. On my system, the outputs in artnetnominator look identical in both 2023 and 2025 builds.

The warning is caused by a packet sequencing bug in Packet Per Channel mode when sending >1 channel (and also an issue with the DMX Out POP). Basically, the packets are not stamped with the correct sequence number, so even if they do all arrive it may confuse the receiver. However, this bug exists with both Art-Net and sACN, so I’m not sure what the difference is there, perhaps the sACN receiver is less strict with its sequencing validation.

One way you could test that this is indeed the source of your issue would be to construct the same test case using a bunch of DMX Out CHOPs each in either Packet Per Sample mode, or in Packet Per Channel mode with just 1 channel. If this resolves the issue then it is indeed caused by the packet sequencing bug, but if not I’ll need to investigate further.

Anyway, I’ve fixed the bug with the broken packet sequencing in Packet Per Channel mode and for the DMX Out POP, and that fix will be in the next official build we release: 2025.33260+.

@eric.b

thanks for the quick reply!

I tested it with the packet per sample option and the warning did indeed disappear, so no further investigation is then needed.

looking forward to the next version.

thanks again for helping!