ArtNet VL Plugin

inspired by the module that @MSBERGER did a few weeks ago i took this to VL, see attached. please use latest alpha when trying this.

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).

@kalle @catweasel @karistouf @Westbam
that any good? (7.7 kB)

Well that seems pretty efficient 128 uni at above a min 25fps :)

and here is the complete thing: sender+receiver.
again needs latest alpha to test.

regarding performance i expect improvement as soon as the udp sender/receiver are available in VL. as you can see now the data still has to be moved back from VL to vvvv… (17.5 kB)

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…

ai cat, i should have mentioned here that the download above is obsolete und you can now simply use the ArtNet (Network Sender/Receiver) modules shipping with latest alphas. hope that helps.

Thanks Joreg, I was using it with a none alpha (prokector) version.
Any idea when UDP might be VL native? Autumn would be good ;)

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.

I tested sending 128 universes of DMX and the patch was running above 25fps, the project I haven mind is 384 universes, and ideally would run faster than 25fps ;)

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).

Doesn’t have to be 60hz ;) But Gbit should handle the data, but v4 won’t without a more efficient UDP node…
Its another version of this

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

artnet test (5.5 kB)

the ArtNet (Sender/Receiver) come with helppatches. if you open both you should see them communicate.

in your example sender and receiver are set to different ports. setting both to the same (and adjusting the ip) works for me too.

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?

not sure what you mean by that?

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!

last paragraph of

just to add, I’ve been using address less than 15 for testing

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)?

white cat by @karistouf?

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)

humkay…had a go at whitecat but can’t seem to figure out how to just quickly test if it receives artnet… anyone knows?

same for the vl artnet node…

maybe this can help:

EDIT: I haven’t checked it out before, but it seems to do what you want it to do

EDIT2: it looks quite nice and can see the stuff from the VL Artnet nodes