I’m really liking the DMX POPs workflow, it saves me a lot of time vs the old pixel mapping method I was using. My setup is fairly unique and instead of using universes and a standard DMX architecture, each fixture has a DMX receiver with a unique IP address. Laying out DMX channels with the DMX Fixture POP seems to map based on the internal primitive index attribute, and when I have multiple fixtures off of a single IP, I end up needing to enter the same IP into the routing table with an entry for each primitive.
It would be great to have a net address parameter that would override the net address in the routing table for these fixtures that use a single IP, while preserving the ability to route primitives to different IP addresses since that works very nicely. My current solution uses DATs to rewrite the netaddress column but it’s pretty messy
would be very interesting to see how you are setting this up for your unique case. You can do the addressing fully by specifying IPs as attributes as done in the OP Snippets example called “moving head light with addressing“ of the DMX Fixture POP. Attributes available for addressing are:
DMXFixtureNet (uint)
DMXFixtureSubnet (uint)
DMXFixtureUniverse (uint)
DMXFixtureChannel (uint)
DMXFixtureNetAddress (uint4)
But please do share your current setup approach, we might be able to recommend some simplifications.
Thanks for the prompt reply The OP snippet was helpful! I am using the DMX Fixture POP routing table to address based on primitives (since each fixture has multiple points). I attached a file with an example of my setup. I’d appreciate any suggestions!
what I have come to at the moment is that I define a fixture type as a component and then use a Copy POP inside the fixture to multiply the fixture and put it into place where it is needed.
The first input to the fixture component is then a Point POP with as many points as I have fixtures of this type.
On the Point POP I can define attributes like DMXFixtureNetAddress to give every fixture an individual ip. A nice sideeffect of this is that now other operators can be used to manipulate these settings. In the case of the flood lights, i can use a Pattern CHOP and a Lookup Channel POP to overwrite the 4th component of th DMXFixtureNetAddress attribute to fit my needs.
A bit unusual is the texture lookup outside of the fixture component - full credit to @function.store who proposed this workflow when looking at some examples of dmx fixtures - but this let’s you deal with attribute lookups for your fixtures outside the fixture components. Those you don’t have to touch anymore at all.
Does this setup make sense or do you see other issues? Happy to explore this more.
Interesting, this is an elegant way to handle to duplicating fixtures. I see how setting the IP using the point can be really useful. I will explore using the Lookup Channel POP for my case, possibly with a DATtoCHOP for a table of IPs.
The OP snippet was helpful! I am using the DMX Fixture POP routing table to address based on primitives (since each fixture has multiple points). I attached a file with an example of my setup. I’d appreciate any suggestions!