it is actually very similar to msbergers version only also allows you to send variable length DMX packets per subnet/universe and spread the udp-port. and it seems a bit faster.
when you look at the VL patch you see that there are quite some workarounds still needed because of still missing nodes but what you _don’t see is any handling of the actual spreading! the ArtnetEncoder node is patched to deal with exactly one packet, the spreading we get for free by simply using that VL node in vvvv (short story).
This seems to be missing the clamp node in VL? Any idea when UDP might be included too? Might need to run a lot of universes for an upcoming project…
Actually it will probably be using Ki-net, so like artnet, but not…
i’m afraid VL still only works with alphas…
i’d love to be able to give you a timeframe for VL-native-udp but i simply can’t say more than we’re working towards that (and other features) with full force.
can you elaborate on that one? i am not sure i get it right.
thats +64k rgb fixtures!
with 60Hz refresh rate, thats a whooping 90Mbit/s of raw data. wow!
the last project for fusion had a hardware potential for 16k rgb fixtures, and we already had to jump hoops to get that working smoothly, relying on udp and all (vvvv udp node is kinda “bursting” data, some equipment can’t handle those peaks too well).
So just checking the nodes again, and I can’t get this working…
Can you make a help patch?
Latest Alpha, trying to debug with a receiver in the same patch, as my device is not getting anything, but the receiver is not getting anything either
Ah ok, so they default to different ports? Seems odd, and not like previous functionality.
Also the universes IoBox is limited to 16, as is the dmx version, but supports up to 255 presumably (as does the DMX one) ?
Also I notice that the receiver outputs null except on change, again not the same behavior, is there a reason there not a S+H in the subpatch?
Still not getting anything from my fixture though, works as expected with the dmx node, I tried broadcast and unicast. Tried different address and different nodes (arduino LED nodes), also slowing sends down to 1/10th second, however when using a enttec node and a parcan I get output. Any idea why there would be a difference between vl and vvvv?
different ports of the modules was not intended. fixed.
my understanding of the art-net specification is that it has 16 sub-nets with 16 universes each. that’s what i get from the art-net specification. i might be interpreting it wrong. if so please point me to the correct spot in the docs.
regarding s+h: indeed my bad. fixed.
hm…how does your setup differ from a few weeks ago when you said you tested it and it was slow? i assume it was working for you back then?
Previous tests were sending and receiving on the same machine, mostly testing how many universes could be sent
1/10 of a second bangs on send rather than every frame, incase there was an overload somewhere in the receiver
16 universes was v1 art net v3 uses a 15bit address allowing 32,768 universes, not too much to ask is it ;)
The current DMX nodes support universes greater than 16 already, by accident if not design then!
absolutely my bad, didn’t read that to the end. added the Net parameter now allowing you to address all universes.
have to say i also only tested it on local host: sending from old dmx-artnet nodes to the new ones and vice-versa. i was hoping since that works, that would be enough… but the old dmx-artnet nodes have a bit more stuff implemented of the whole artnet-protocoll…
do you know of another simple artnet-receiving software i could use to test (in my lack of an actual device)?
The arduino only uses the basics of Artnet, just listens on a port and takes packets sent to the right universe and subset, which makes it odd it’s not happy here… Can accept more than 16 universes so maybe it’s the byte is different?
Not sure what other software receives doc on PC though (apart from white cat)