did a quick test with newest alpha, Enttec ODE and a DMX-tester as sender/receiver.
I can not see any problems. Sender and receiver work without any problems out of the box.
I of course can not tell anything about performance in my current little setup … but generally everything looks fine !?
Is there anything special i should/could test ?
Markus
@MSBERGER supa to hear, thanks for testing.
@catweasel can you maybe elaborate on your problem then so that msberger can mabye reproduce?
Well with my arduino nodes, the dmx node works fine, but the vl doesn’t fo anything! Not anything more to say! I’m prepping a show for the next couple of days, but next week I’ll try and debug via the arduino with serial monitor and see if I can find out what’s being received
did you find the time to check again ? is your problem solved ?
What code on arduino-side (i guess the arduino is the receiver - right ?) are you using ?
As i had a arduino with ethernet shield on my desk anyways i did a few quick checks today.
The new VL-artnet-sender-node seems to work fine with artnet-arduino-set-v3.1-0 and also https://github.com/natcl/Artnet !?
Not managed to check again yet, waiting for my kit to come back from a gig!
I’ve just checked with a different implementation of artnet than the one I was previously using and it seems to work fine, so I guess it was my more arduino coding :)
@catweasel good to hear.
now: can you elaborate a bit on the 384 universe usecase you mentioned above? would that be you creating a spread of 384x512=196608 slices to feed to the artnet node? to my unerstanding udp defaults to ~8k which would be 15 universes per udp-port. so you’d also want to spread the ports, right?
I’ll be honest, I’ve no idea, all I know is it is supposedly supported, I’m not sure if the ports get spreaded or not, with the current native vvvv nodes, I’ve tested unto 40 universes, so it doesn’t seem to be limited to 16
jaja, i’m not saying there is a limit. i was more interested in how you’re planning to operate the 384 universes from vvvv (slicewise…).
What ever way I can! But yes, I guess a lot of slices, that job hasn’t happened, but thats not to say it won’t appear again ;) I’d probably pipet them from a texture (dx11 of course!)
ok and then we’d still need to know how an artnet-hardware would want to receive those universes udp-portwise. because there to my understanding is a limit of what you can send in parallel… any @kalle or @MSBERGER with some insights on practical artnet limits?
I will bump into this this Thursday where I will be working with two of these: http://www.advateklights.com/shop/pixlite-pixel-mapping/50-pixlite-16-mkii-control-board.html
not sure I will need all 96 universes on each, but pretty close to that
it seems to work great so far.
there is a little thing, the LED controller is using universe number all the way up to 96, and in vvvv, I have to split them every 16 universes into a subnet. that also works fine, but for using a number of universes that is not a multiple of 16 force me to think about how I divide them up into universes and subnets and they have a different numbering. Relatively simple but still a bit annoying.
Perhaps it would be good to add a kind of speedlimit to it, it seems like it is possible to crash the controller if I send too much data to it.
Perhaps a default of 20fps
re numbering: hm…but that is the ArtNet way of addressing it: 128 Nets with each 16 Subnets with each 16 Universes. now i’m totally unfamiliar with artnet-devices…would you say we should not talk about Net, Subnet, Universe but rather only Universes? how are devices or other software talking about this?
re speedlimit: not sure i’d want to add that to the artnetnode, but there is a Limiter (Animation) node in vvvv and a Throttle [Control] node in vl that could help.
and another update. b35 is now shipping with native UDP nodes which should allow us to optimize performance quite a bit. so if anyone is looking for improved artnet-performance please start a new forum topic…
I typed this, some time ago, but for some reason I did not post it
I am not too familiar with other devices than the ones I have used and on these boards, they name them universes from 1 and up to 100: http://www.advateklights.com/shop/pixlite-pixel-mapping/50-pixlite-16-mkii-control-board.html
I made a little modification that can be made into a module to have this addressing, that might be a solution to having different addressing standards.
regarding Speed limit, I agree, it is easy to limit using eg. LFO change output into send.
here my first arnet story:
We first used one Artnet with 0 to 15 universes. The Controllers (DigiDOT C4 live) uses 4 “DATA” with universe 0 to 11.
When we send it to more than one IP the universes 12 to 15 come into the second controller. If the artnet node where not limited to 16, everything would worked out fine with autoconfig of the controllers and my first development in vvvv.
Than we end up in numbering der universes 0-11 in each controller with IP and have one artnetsend for each IP.
The real magic is ordering the spreads for the data, the project has not finished yet, there will come more led modules with other universe dimensions and so on. vvvv was also great for fixing hardware mistakes like, 2 universes where wrong soiled, so I reveresed them in booth directions … ? … worked out fine, not sure about performance.
Here is my patch for ArtNet to C4 for 2 full controllers.
artnettoc4.v4p (233.6 KB)
I had not time to get a look to VL, will get on it soon.
Ok, im missed this threat… I configured the node as i need! …will post a updated and tested version.
:)
lovvvve
tom
4 bytes subnet, for universe …hmmm…
it should work with subnets…
@sunep I tested it, but i had the fixed setup very late for real configuration testing. thx for that