I am currently trying to control approximately 400,000 LED volumetric light particles using DMX Out POPs.
When I open this project in the latest TouchDesigner version (32280), the performance drops to around 1 FPS. However, if I unplug and replug the LAN cable, it recovers to 60 FPS.
The same issue occurs when I open MIDIDeviceMapper: the frame rate drops to 1 FPS, and unplugging/replugging the LAN cable fixes it.
Additionally, even when TouchDesigner is running at 60 FPS, the LEDs themselves display with severe latency.
For Art-Net output, I am using a 10GbE interface. The signal goes through a 10G switching hub and is then sent to each LED over 1Gbps connections. According to the switching hub, the receive rate from TouchDesigner is about 373 Mbps, and each output port going to the LEDs is around 92 Mbps.
I would like to determine whether this latency is caused by machine performance limitations or if it is due to a bug in TouchDesigner.
Have you tried sending via unicast instead of broadcast? Unicast will generally be quicker and more efficient for sending to a single receiver, and can avoid overloading the network, which is especially important when sending so many packets per frame (2432 in your case).
In your example, I’m able to reproduce some of the behavior you’ve described, and upon inspection the socket does seem to be really struggling to keep up with the packet rate. If you inspect the DMX Out POP’s Info DAT values then you’ll see what I mean: packet_rate is stuttering and ArtSync times out repeatedly, and never sends, which means it can’t process a frame’s worth of data before the timeout. When I switch to unicast it has no trouble keeping up.
Thank you for your reply
I am not sure how to configure Art-Net unicast output.
Could you explain the correct setup?
At the moment, one IP address is assigned per Universes 0–15,
and the IP addresses in use range from 2.0.0.3 to 2.0.0.154.
for a programmatic approach, you can assign the ip addresses to each of your primitives (dmx fixtures) by adding a primitive attribute of the type uint with size 4 and calling it “DMXFixtureNetAddress”.
This addressing becomes easier if the concept of what a fixture means in your example is explored.
In your case, a fixture could be described as the element that consumes 16 universes.
For this we can setup your fixture as a single Line Strip primitive as done here:
Now we have a single primitive that we can add an address to.
In your case the wiring is a bit interesting as the second half of the 72 strips that make up a element has a different strip order. I was able to use the base structure from above and a Limit POP to loop elements from the second half to form the correct shape. By being able to use the COPY POP here, I’m also able to add an attribute to each primitive with a IP address offset, knowing that my combined 2 elements will occupy 2 IP addresses.
This now is the basic element for your installation and I can copy this onto a 6x6 grid to create the main volume as well as onto the 40 point line to create the secondary volume.
Here again, I add a attribute IPOffset to each template point which in the Copy POP is added onto the IPOffset attribute of the fixture itself. The IPOffset channel is of the type “Ramp Samples” with an Amplitude of 2 as to increase by 2 per copy.
Finally I use a Math Combine POP in which a new attribute called “DMXFixtureNetAddress” is created and is set to the start IP address for that part of the installation. On the Math Combine’s “Combine” parameter page, the IPOffset attribute is added to the 4th element of the DMXFixtureNetAddress to increase this as needed per fixture.
The result is that now every fixture has it’s own ip address and you have a unicasting setup.
Thank you for your explanation.
I tried assigning the addresses, but the primitives no longer match the DMX channels correctly.
What might be causing this issue?
The IP configuration is correct, however at 2.0.0.4, where Primitive 36 should be received, no data is coming through.
From that point, the mapping becomes progressively misaligned, and the expected results are not obtained.
Up to 2.0.0.18, the output was working correctly. However, when it reached 2.0.0.19, the subnet wrapped around and returned to 0, while the net value remained at 0, and the universe_num also reset to 0. As a result, the LEDs from 2.0.0.19 onward were not lighting up.
After adding DMX Fixture NET, I was able to get the LEDs to light up correctly.
