I have some artnet controllers running off esp32’s, and they dont like artnet from gamma, I think its becasue their buffer gets overloaded (dose gamma send them all at once?) , so sending 8 uni from gamma it stutters, but if I send 1 uni per frame at 360 fps (or even 720!) , it works fine.
So what is the correct way to do this, send packets one after another?
that is very fast for dmx, what are you controlling?
It’s only sending 1 universe per frame, so divide the frame rate by 8 for the refresh of every universe rate. It seems like maybe vvvv sends all the universes at the same time rather than sequentially.
On beta I remember that I have to limit the send nodes with a LFO 1/30, if not some old Dmx interfaces did not like it…
Also, the ESP32 RX buffer over wifi is not too big… how many universes are you sending ? and what else are you doing with the IC ?
Did you try sending data from another software like Resolume or vvvvBeta?
I’m running LED’s, using Resolume it is silky smooth, in gamma very stuttery, 1 or 2fps. With Resolume I have had 16 universes / 16 pins of the esp32 running smoothly. I thought it was the boards until I tried Resolume and realised gamma had an issue with them. Solution is to send packets one after another, question is, the best way of doing that.
a global “bang” for all the 16 send nodes?
and for each universe do a Delay node with value unviverNumer*0.0625 ( 1/16=0.0625 ) ?
Try using Wireshark to measure the time amonng packages
can you share a patch that show’s how you’re doing this?
HowTo Send ArtNet.vl (29.2 KB)
Which is ok, and could proably be wrapped in an async loop, but ideally I’d like to be able to have a set frame rate eg 40fps and the frames would all be sent as qucikly as possible, but sequentially bunched up at frame start, or if they already are sequently, then, being able to slow it down if needed.
i’m afraid i find it hard to help you here. your patch is a mess and using the now obsolete artnet nodes that have been completely revamped in vvvv gamma 6.3. so i’d advise you look at these helppatches and start from there.
i don’t exactly understand what you’re hoping to do but either way it doesn’t sound too complex and most likely does not need an AsyncLoop (as you mentioned).
@joreg from the example patch on 6.4 HowTo Send and Receive ArtNet
try this
Set up width to 0 and manually move the value, its taking like 120ms to update on the RX part
Well if you can’t work out how a slightly modifed help patch, that was the previous versions helppatch with added multiple universes, is working, where all I’ve done is add some nodes to help debug, and send frame by frame, you need to do more patching in the field under deadlines.
And yes it was using the 5.3 version, because as I have mentioned elsewhere, 6+ has been breaking other things that I am using. The patch I am trying to fix is a patch from earlier in year that I was using on a project where I nearly lost the gig, because the artnet wasn’t working, but I fashioned a horrible work around, blamed the wireless nodes we had to use, it had to run off batteries, and that I am now trying to fix for future runs.
Will I update that patch to 6.3 (which does seem to fix the issue, so well done on your rewrite of the artnet nodes) no I won’t, as mentioned above breaking changes. Will I do so at some point when I’m not on another deadline with a load of soldering to do, probably.
@catweasel i’m sorry to hear you’re having such a rough time there but you know we’re always available for help. only, when asking for help it really helps a lot if you’re not sharing a patch with unrelated leftovers and without any comments where we now first have to sift through all those things and guess what your problem is. you know everything, we know nothing, so please help us get in your brain by trying to be clean and precise.
the patch you sent was last saved with a 6.5 preview. how is anyone supposed to smell that you need to work with 5.3? so, ok, we’re on 5.3, now:
i’ve read this a couple of times now and am afraid i just can’t work out what you’re after. please try to rephrase.
This patch uses a frame counter → mod(number of universes) to send 1 universe per vvvv frame, with vvvv running at (number of universes)* artnet refresh rate. Ideally 40, but I pushed to 80+ to see how fast I could send multiple packets before experiencing the stuttering that I got with out using this method.
I therefore concluded the problem seemed to be that artnet was being sent as either one large packet containing all the universes, or maybe serial but so fast the controller dropped most of them (the contoller has to recieve all universes before outputing to the pixels)
Sending them the way I am now they are evenly spread in time so at 40fps the first universe with be 1/40 ahead of the last, this will cause tearing of fast moving gfx. So I’d like them as fast as possible, but slow enough that none get lost. At 40fps, I’d like them as close together as possible at the start of the frame.
I realised vvvv was at fault last week when I sent artnet from resolume and it was silky smooth. Its a workaround and only affects this one wireless reciever, but I like to know how to fix things because when onsite and things fuck up, I have to fix them, and in this case I can’t run the patch at 320fps.
my understanding is that artnet requires universes to be sent as individual packages, so that’s what’s happening here. so yes, if you put a loop of 8 around the ArtNet (Sender) node, it will send the 8 universes within a frame but in 8 udp packages.
now you’re saying that is too fast and add the FrameCounter>mod to only send one package per frame and say this is too slow, right?
how about: remove the framecounter>mod thing, ie just a loop around the ArtNet (Sender) sending all universes in one frame. but now control the update rate via the MainLoop node. set the mainloop to 10, does it work? set it to 40, does it still work?
I’ve been through all that, yes it works, but only at low frame rates, after about 10-15fps it starts stuttering badly, ie it hasn’t received packets and waits until it has got all the universes before updates so the frame rate becomes more and more erratic.
As it’s fixed in 6.3 forget about it, when I’ve time I’ll update my pixel mapping patch and for now I’ll use just resolume.
As a hacky temporary solution, you could UDP from the 5.3 patch to a 6.4 patch that send the data as artnet.
here’s a thing you can try: install the latest vl.io.artnet pack in the vvvversion you’re running. at least the sending should work (seems you don’t need to receive artnet, right?!).
then try a patch like this:
HowTo Send ArtNet to multiple universes.vl (7.8 KB)
1 Like