FIXED: [099 2017.6800] DMX Out sACN packets off-by-another

Thanks for the fix to the DMX Out CHOP that was causing crashes.

I don’t know when it was introduced, but now there’s a rather subtle bug in that the sACN packets that TD sends out have a byte that is off by one bit. Unfortunately this is not enough for Streaming ACN Viewer to reject them, but it is enough for MA Lighting’s console to reject the packets so it would’ve been tough to troubleshoot unless y’all just ahppened to have a $30k lighting console laying around.

Basically, octets 123-124 of the UDP packet should be 0x0201 but in TD’s implementation it spits out 0x0200. That part of the packet is just indicating “Property value count” but as far as I know it will always be 0x0201 in the case of sending DMX packets, since there will always be 512 DMX channels sent AND it also needs to count the start code (which should be 0) which makes 513, hence 0x0201.

When I send to sACN View it works either way, but when I send to a console it does not. I tried flipping that specific bit between 0 and 1 in my old UDP Out based sACN sender and it made all the difference in the console being able to see it. I guess the Germans are just more requiring of strict standards compliance than whomever made sACN View :-/

Great catch, and thanks for posting.
This will now be fixed in the next posted build.

Cheers
Rob

Thanks! Although now there’s an extra 0x00 byte at the end of the packet for some reason. sACNview doesn’t mind but MA still don’t like it. :slight_smile:

Any chance the same Property Value Count fix can be applied to the DMX In CHOP too? :smiley: :smiley:

Okay thanks for the followup.
We have a fix that we’ll coordinate with you before releasing.
Cheers,
Rob.