I’m attempting to use the DMX Out POP to send 18,000 channels of data and I’m getting around 7fps. Is that way beyond the intended scale or should something that size be able to run decently?
It’s for a volumetric panel with 6000 RGB leds. Ideally I’d like to be able to run up to 36 of those. Doing it with TOP → CHOP → DMX gets down to around 30fps but that’s significantly better than 7.
Resolume seems to be able to handle it at a decent frame rate. It has other issues with ArtNet but it at least indicates that it should be possible to send that volume of channels.
Is that 7 fps running 6000 RGB LEDs or running 36 x 6000 RGB LEDs?
We’ve made some significant performance improvements to the DMX POPs that will be available in the first experimental release. I think there’s still some more room for improvement, so I consider it a work in progress. If you’d like, you can also send over your project so we can use it as a test case.
A single panel is 60x10x10 LEDs. The attached test file just attempts to do that.
pop-sender-example.toe (9.8 KB)
Using the old CHOP-based approach we attempted it with 33 of those panels (with 3 additional that we didn’t use), so 60x10x10x33 LEDs, and got around 30fps.
Thanks, yeah there are currently some performance issues when using DMX POPs with connectivity other than ‘None’. We’re looking into it but for now you should be able to work around it by setting connectivity to ‘None’ on the Grid POP.
1 Like
That helps a lot. I’m now getting around 35fps with 6 panels.
If we have multiple devices where each has a different IP, is there a way to send to all of those via a single DMX Out POP? It supports a routing table but there aren’t any examples and the wiki says “..by adding rows for each channel..” and it isn’t clear how that applies to pops.
Is that 35fps with the experimental release (2025.30060) or the latest Alpha build?
Thanks, that was a typo in the docs – I’ve fixed it.
The routing table allows for overriding of network addresses on a DMX512 universe basis. So, you specify the net, subnet, universe combo that the row applies to, then specify a netaddress to override the DMX Out POP’s parameter value. It works much the same way as the routing table on the DMX Out CHOP.
Additionally, netadress can be overriden by the DMX Fixture POP by using its routing table on a per primitive basis. Or instead of using a table, a DMXFixtureNetAddress primitive attribute can be used on the input, which must be of type uint[4].
1 Like
It was on the alpha build but now I’m getting 50-60 fps with the experimental build.
Sounds like using the same universe address but different IPs isn’t a good approach in that case. But spreading them across universes is feasible.
Thanks, yeah there are currently some performance issues when using DMX POPs with connectivity other than ‘None’. We’re looking into it but for now you should be able to work around it by setting connectivity to ‘None’ on the Grid POP.
To expand on this a bit more: the problem is more specifically to do with Point Prims. This is because conceptually the DMX Fixture POP considers a primitive to be a fixture, and that dictates how the DMX Profile is used to construct the channels. In your case, that might be better served by a single line strip connecting each point, or more simply, having no primitives so that they are all automatically grouped together (ie. connectivity=‘None’).
Now, the core of the problem seems to be that there’s a bit of overhead that comes per-primitive (ie. fixture) when generating channels, which when using a lot of primitives (which is often the case for Point Prims) can create high cook times. I’ll look into how we can improve some of this per-primitive overhead to fix these high cook times, but at any rate, I think a line strip should be used in the aforementioned case. You can connect all points in a single line strips by using None connectivity, wiring to a Primitive POP, and setting line strip on the Primitive page.
EDIT: There is a bug with universe creation that causes a slow-down for high numbers of primitives. This will be fixed in next experimental build we release: 2025.30154+, and will fix the high cook times with Point Prim connectivity.
3 Likes