Hey there,
It would be great to have a mode that constructs universes by IP Address (or even groups of addresses) and allows overlapping of (DMXFixture-) net, subnet, universe and channel.
Currently only the first primitive in a POP of multiple primitives with different IP addresses but identical net/subnet/universe/channel gets processed.
Use case: No need to configure each sACN/ArtNet node to use a specific universe/subnet/net. They can all be left at their default settings and be addressed using IP.
Specific example: WLED fixtures configured by importing a configuration backup. They all share the same sACN/DMX Config. Instead of calculating and configuring the start universe and address of each device, I like to assign their MAC Addresses to specific IP’s in my DHCP server and address them that way.
This may be a little niche and is probably already possible using a DMX Fixture POP per target IP.
Are you using the routing table with the netaddress column to organize fixtures by IP? It’s true that only one entry per primitive/fixture ID is allowed that way, so you would need to copy your input to create more primitives to send to different IPs, which I know isn’t the cleanest solution. Extending the routing table to allow for repeating the same primitive to send to different IPs might be an okay solution here. I’m curious your thoughts on this.
Also just as an FYI (I don’t think it will directly help with your case), you can set net, subnet, universe, channel, and netaddress as primitive attributes on the input:
I was already using point primitives with DMXFixture* primitive attributes and a copy POP to set up multiple primitives. After looking at it today, I realised the problem manifests itself in DMX Out instead of DMX Fixture.
Please take a look at my example file. I added comments to make things clear and provided a working and a broken example.
point_fixtures (working example)
Individual IP Addresses and individual universes.
point_fixtures_broken (broken example)
Individual IP Addresses but identical universes.
Thanks a lot!
I love how DMX works with POPs by the way. The routing tables are a nice way to get started, coming from the DMX Out CHOP, but the DMXFixture* primitive attributes really make the new system shine.
It’s awesome to have such an easy way to build each fixtures DMX Table and map them in 3D using the P attribute or other custom attributes like Prel in my example.