Artnet DAT should get ArtPollReply from DMX In CHOPs in TD

Maybe I am wrong, but it seems to me that TD with a DMX In CHOP in ArtNet mode could be considered and ArtNet Node and thus should respond to ArtPoll with ArtPollReply.

Practical application in my case is to explain polling in an online workshop and that feature would allow me to have many virtual ArtNet nodes, that in the best case behave like real ones


p.s. while we are at it: The documentation needs some love. e.g. there is no mention of the address column in the dmxin filter table. I think it can be used to put in an ip and only get packages from that IP, but is definitely not explained anywhere, except by Pete in a forum discussion, which is great but not exactly a help file ; )

Good suggestion. That’s definitely something we can add.

We renamed the “address” column to “srcaddress” to avoid confusion when we added “destaddress” to the filter table. Both column names should be present in the filter table by default, and “address” can be used in place of “srcaddress” for backward compatibility reasons. These are documented in the Summary portion of the DMX In CHOP

ups, I was accidentally working in an old version of TD,
where there were much less columns on the DMX IN, sorry for that! Went back to the latest official.

Now, I get the usage of srcaddress, but I am a bit confused about destaddress. When I have DMX In and DMX Out open in the same network, I would assume that srcaddress and destadress need to be the same, as both live on the same IP. However if I fill that in the table, the DMX Out doesn’t receive anymore.

Could you be so kind to explain what destadress refers to / should be in this case, if not the IP of the receiving device?

And would it not be something that the DMX Out has to have, so it sends only to certain IPs?

I feel like I have a proper missunderstanding here…

Thank you,

“destaddress” refers to the address of the receiving network interface, but only in the case when the source is unicasting to the interface. More generally, it’s the address the source sent the packet to, it could be a broadcast address, multicast, unicast … It’s not particularly useful if you only have one network interface. Even with multiple network interfaces, it can be left blank in the vast majority of cases because filtering universes by destination address isn’t often necessary. I imagine that’s the case for you as well.

That being said if you did want to use it in your example the “destaddress” would be the address you’re sending to in the DMX Out CHOP. It may or may not be the same as “srcaddress” because the “destaddress” could be a broadcast address, for example.