UDP Sync with WLED about colorchord.net HOT 24 OPEN

Hi again!

I guess that's not too surprising. 490 LEDs x 3 colours = 1470 bytes, add the headers and other stuff and that's right in the neighbourhood of typical network MTUs, the maximum size for single transmissions. Any packet larger than this gets fragmented (split into multiple parts), and I'm guessing the network stack in WLED doesn't support UDP fragmenting or jumbo frames. Fair enough.

I'm a bit busy right now, so it'll probably take me a few days to get around to this, but implementing one of those protocols doesn't sound too bad. (I found this documentation on TPM2.net). I also really should port some of the 2D LED matrix visualizers over, as right now CC.NET doesn't have much in that regard (Cells is probably the only one that'll look half-decent).

I'll let you know once I have something for you to try out.

Thanks for stopping by!

from colorchord.net.

I just added a config option to make all TPM2.net packets equal in length. You can add

    "ConstantPacketLength": true,

to your config (in the PacketUDP section) to achieve this.

@123vollhorst Could you try both this, and the 768 length, one at a time to make sure they both work correctly on your system?

@Aircoookie Thanks for stopping by and providing insight! Always nice to see developers of larger projects interacting and helping out in the surrounding community :)

from colorchord.net.

@qu4nt4r Hello again!

Sorry for the long delay, I've been quite busy lately. I've implemented some basic LED matrix handling in the newest auto-build which will hopefully make things look a bit nicer in your setup. Would you be willing to give it a try and let me know how it goes?

If so, here's what you will need to do:

• Grab the newest autobuild (110+)
• Download and install the .NET Runtime 5.0 from Microsoft, as I've updated ColorChord.NET to the newest version.
• Set a few config parameters to match your matrix layouts

For example, the way you described the "right light", I'd guess the config options would be (under the PacketUDP entry):

"ZigZag": true,
"Mirror": false,
"RotatedArray": true,
"SizeX": (however long one of the strips is)
"SizeY": 2

Hopefully this will address your last two points.

I'm very curious about the issue with the circular mode, it shouldn't have any different limit than regular mode. Is this still reproducible on the newest version?

Thanks!

from colorchord.net.

Sadly there is no easy solution for this from WLED side as Aircookie (the main dev) mentioned. If you may find a workaround for this problem from the CC side to get this running this would be really cool.. I then at least could offer to write a short paragraph at the UDP-part within the WLED wiki to mention your CCnet work. I am pretty sure that there may be others within the WLED community that may like to use the software.
greetings
Kelvin

That software seems cool! Unfortunately there is no way of raising the UDP packet size with the current network stack, so 490 LEDs are the ceiling for any given packet 😦 WLED supports several protocols that split the frame into multiple sequenced UDP packets (E1.31, Art-Net, DDP and TPM2.net, with DDP and TMP2.net being the easiest to implement with the least overhead since they don't aim to be DMX compatible with all the universe stuff). If the ColorChord developer would consider adding one of these standards, driving a 1024 LED matrix should work fine (I believe one guy even got a 2k matrix working once) :slight_smile:

from colorchord.net.

Ah, that explains what's happening then.

I'll also implement a config option to pad out the last packet, since receiving systems other than WLED may also not like variable-sized packets. I was just expecting reading of the last packet to fail if any, not the first one/multiple.

from colorchord.net.

I personally don't use WLED so have no way to test. However, CC.NET should be able to achieve very high throughput rates, easily enough to saturate the connection of an ESP32 or other similar device, as long as you configure the settings aggressively enough.

Unreasonable example: I asked it to output 10000 LEDs at essentially uncapped framerate, with 6 bytes per LED. This is just to show that you can scale to (almost) whatever data rate you want to test with.

It might be worthwhile to run Wireshark on the sending device just to make sure that everything's being sent as expected. TPM2.net support is still a bit experimental, so it's entirely possible I made a mistake, and something isn't being sent right.

from colorchord.net.

Hello, thanks for stopping by!

First time I'm hearing of that project, and by taking a glance at the linked UDP packet structure, it does require the first 2 bytes to have special data. Since we'd want to use their DRGB mode, we need byte 0 to be 2. Since ColorChord.NET will fill all padding bytes with the same data, that means as of right now you're forced to use 2 seconds as the timeout value as well (byte 1). If that's fine, set your PacketUDP config section to have these (in addition to the address, port, etc):

"PaddingFront": 2,
"PaddingContent": 2,
"LEDPattern": "RGB"

This tells it to have 2 bytes of padding at the front, both filled with the value 2, then all of the data in [RGB][RGB][RGB]... format

Note the config parameter names are case-sensitive (which is why you get that warning, since you had "paddingcontent" instead of "PaddingContent".

Could I have you try that out and let me know if it works?

from colorchord.net.

Thanks! Though I still got a "[WRN] Unknown config entry found: ... with all three config entries while using the release build, it worked fine using the actual auto-build (config seems similar). I will play around with the config possibilities to get a bit more familiar with the options. Any other advice regarding the performance/for optimization?

from colorchord.net.

Ah yes, sorry about that. I forgot to mention the release version is a bit behind at the moment for config options.

Regarding performance, the biggest tip is to just remove things you aren't using. The default config has a DisplayOpenGL window shown on the desktop. If you don't want to see it, just delete that whole entry from the Outputs section. If you're just using 1 visualizer with a PacketUDP output, I've seen extremely good performance. Just for testing I was able to push 300+ FPS with 100s of LEDs per packet, without too significant CPU stress. I can push 100+ Mbps just in UDP LED data without maxing out a core.

For my daily usage, I'm outputting 50 LEDs at 90 FPS over UDP only, and even on the several year-old laptop I use in my media center, CPU usage is under 1%. I built a custom Ethernet-connected RPi receiver that has no trouble outputting this.

In short, just turn off unused things, and performance shouldn't even be a concern on the PC side. I'd be much more worried about the ESP32/receiver being able to keep up.

from colorchord.net.

Thank you for sharing your experience, I´ll dig into it. Keep on doing what you´re doing :)

from colorchord.net.

Hi there its me again :)
I took a look at your port again and in general it works fine with my WLED based lighting fixtures. But as I added the second one, a 1024 LED matrix, it just didnt react to the UDP streaming while my first one worked without any issues with the same basic config. After trying out a lot of random stuff, I found out that there is a limit regarding the LED amount. It is exactly 490, 491 doesnt work. The number doesnt make any sense to me. The matrix works fine with any other UDP based audio-reactive software, but I atm have no clue why not here. I will investigate it further as good as I can, but maybe you have an idea regarding the cause and/or for a workaround/solution.
Greetings and thanks :)

EDIT: Ok found it. Its the max cap of the DRGB protocol. Will take a look at the WLED side if there is a solution to this one.

Here is the config

"Visualizers":
[
    {
        "Type": "Linear",
        "Name": "SampleLinear",
        "LEDCount": 284,
        "IsCircular": true,
        "FrameRate": 60,
        "LightSiding": 1.0,
        "SteadyBright": false,
        "LEDFloor": 0.1,
        "LEDLimit": 1.0,
        "SaturationAmplifier": 1.6,
        "Enable": true
    
        "Type": "Linear",
        "Name": "1024wall",
        "LEDCount": 490,
        "IsCircular": false,
        "FrameRate": 60,
        "LightSiding": 1.0,
        "SteadyBright": false,
        "LEDFloor": 0.1,
        "LEDLimit": 1.0,
        "SaturationAmplifier": 1.6,
        "Enable": true
    }
],
"Outputs":
[
    {
        "Type": "PacketUDP",
        "Name": "SampleUDP",
        "VisualizerName": "SampleLinear",
        "IP": "192.168.1.179",
        "Port": 21324,
        "PaddingFront": 2,
        "PaddingContent": 2,
        "PaddingBack": 0,
        "LEDPattern": "GRB",
        "Enable": true
    
        "Type": "PacketUDP",
        "Name": "1024",
        "VisualizerName": "1024wall",
        "IP": "192.168.1.16",
        "Port": 21324,
        "PaddingFront": 2,
        "PaddingContent": 2,
        "PaddingBack": 0,
        "LEDPattern": "GRB",
        "Enable": true
    },

from colorchord.net.

I also really should port some of the 2D LED matrix visualizers over, as right now CC.NET doesn't have much in that regard (Cells is probably the only one that'll look half-decent).

Thanks for your effort! Btw: Actually 1D and 2D look quite the same. On top there is a 8x128 matrix and at the bottom there is a 1x288 (144LED/m) strip under the stones.
Eager to further play around with CC and looking forward to further improvements. :)

from colorchord.net.

Ah, gotcha. When you said 2D matrix, I was expecting something more similar to this: https://youtu.be/s8qWqYTpCN4?t=52

from colorchord.net.

Actually I also use the ws2812b LEDs. The difference should be the visualizer, assuming Charles uses the voronoi thing in the video. Just for another impression: Here is the cell one, once with time based enabled and once without. Its my shitty cam and the diffusers I use that may distort the impresion.

from colorchord.net.

Alright, I have a first version ready for you to test. Grab the latest autobuild, and edit your PacketUDP config section to look like this:

{
    "Type": "PacketUDP",
    "Name": "SampleUDP",
    "VisualizerName": "SampleLinear",
    "IP": "192.168.0.60",
    "Protocol": "TPM2.net",
    "Enable": true
},

(Override my name, visualizer, IP, etc with ones for your setup)

If needed, specify the port, but it will use the TPM2.net default (65506) if TPM2.net is selected and nothing else is configured. The default max packet size should also be compatible with your network MTUs, but you can lower it with a "MaxPacketLength": 1400, line.

I'm not 100% sure it's correct yet as there was something in the TPM2.net spec that didn't make sense to me, so I went with what was written but it may need to be changed.

from colorchord.net.

Thanks again for your effort! But here we encounter another puzzle... Maybe you can make any sense out of it. In the meantime I will check out the WLED side.

until 488 LEDs: normal normal working behavior
489-496 LEDs: no reaction when started
497 LEDs: LED 2 "working"
498: 3-4 "working"
499: 4-6
500: 5-8
501: 6-10
502: 7-12
...
600: 105-209
...
700: 205-409

from colorchord.net.

Hmm, it seems like it is ignoring the first packet, then reading the second packet and assuming the first packet had the same length. I'm guessing your receiver still can't handle the full-sized first packets, even though they are within protocol specs (I think).

Try adding this line to the PacketUDP config section:

   "MaxPacketLength": 768,

This should split your 2048 pixel display into 8 packets, 256 LEDs each, and I'm hoping 768 bytes is well within the capabilities of your receiver.

from colorchord.net.

@CaiB thank you for adding in support for TMP2.net so quickly! It's always great to see compatibility between projects increase like this.

You precisely found out the issue, I just took a look at the code of the developer who commited a more stable TPM2.net support in WLED and found this comment:

//TPM2.NET
  if (udpIn[0] == 0x9c)
  {
    //WARNING: this code assumes that the final TMP2.NET payload is evenly distributed if using multiple packets (ie. frame size is constant)
    //if the number of LEDs in your installation doesn't allow that, please include padding bytes at the end of the last packet

So that is indeed the culprit. I will attempt to modify the receiving code to remove this limitation, which I believe was added to be able to deal with out-of-sequence packets more effectively.

Thanks again!

from colorchord.net.

Awesome @CaiB and @Aircoookie Thank you very much for bringing both together. Works like a charm with the matrix, such a colorful light combined with my diffuser panels.
Some not-so-important things though you can see in the test vid:

• When using circular=true the LED limit is still about 170?

• Besides my ws2812b matrices I have a fixture (the small one) with a self built matrix. The ws2812b are top-left 2 bottom-left serpentines, while this one is a top-left 2 top-right serpentine. Due to this the light is fuzzier and not optimized for this layout.

• The right light has two connected strips running up and running down. Neither the linear nor circular layout fits here. Maybe some kind of mirroring could make it look like intended.

  Please dont see this as a feature request but more as a inspiration for further releases. I am eager to use the lights for some installations, being pretty confident it will flash the audience. ;)
  I keep on tuning and testing all lights and configurations. Thanks again and keep on doing what youre doing. 👍
  Cheers
  Kelvin

from colorchord.net.

Hey CaiB, great to hear from you... again :)
Sadly I dont have access to most at my fixtures atm, so my testing capabilities are quite limited for the time being (but to be sure latest in summer I will go out and make some awesome lighting events with my stuff ;).
Nevertheless I took my mobile light with a 8x16 matrix and got through your update.

Regarding the mirroring: I think I was a bit unclear. Given a strip (or matrix, doesnt matter in the end) with a length of X LEDs, a mirroring induces the effect twice (or "copies" it) at X/2 (in the middle). Once from X/2 to the right (the end), and once to the left (the start). With this the effect is (mirror) symmetric.
My "right light" is built with 2 144LED strips soldered together at the top, data running from the bottom upwards and the down (It such could also be seen as a 2x144 matrix). But of course this doesnt make sense for a normal 1D strip, as in CC the colors are moving from "both sides" and mirroring would look strange.
If you are interested in some other sound reactive software that uses this, you may have a look at ledFX or the current wled built that have a mirror option.

While playing around some other thing irritated me. The quality is quite bad, but you can see some "wrong colors" at the matrix (e.g. green is pink). Cant remember if I had this issue before, I rarely dissembled the diffusers/stones to compare color correctness. The RGB order is correct (GRB with ws2812b), dont know what else this could be. My actual config

        "Type": "Linear",
        "Name": "SampleLinear",
        "LEDCount": 128,
        "IsCircular": false,
        "FrameRate": 60,
        "LightSiding": 1.0,
        "SteadyBright": false,
        "LEDFloor": 0.1,
        "LEDLimit": 1.0,
        "SaturationAmplifier": 2.0,
        "Enable": true
    }
],
"Outputs":
[
    {
        "Type": "PacketUDP",
        "Name": "SampleUDP",
        "VisualizerName": "SampleLinear",
        "IP": "192.168.0.102",
        "Port": 65506,
        "LEDPattern": "GRB",
        "PaddingFront": 2,
        "PaddingBack": 0,
        "PaddingContent": 2,
        "Enable": true,
        "MaxPacketLength": 768,
        "ConstantPacketLength": true,
        "Protocol": "TPM2.net",
        "Enable": true,
        "ZigZag": true,
        "Mirror": false,
        "RotatedArray": true,
        "SizeX": 16,
        "SizeY": 8`` 

And one last thing that crossed my mind (dunno if its already covered by your matrix config though...). If X >= Y, you want the effect going horizontally. But if Y > X, it should move vertically. Otherwise it looks pretty squeezed...

Thanks again for your work :)
Kelvin

from colorchord.net.

One quick correction. "Mirroring" in my documentation doesn't mean duplicating the data in a mirrored way, it means horizontally flip the entire row. There's no modification to the pattern, just a horizontal reversal of the order of pixels. I hoped the diagrams on this page in the documentation would clear this up. What you're describing in the other software is something different. I hadn't heard of this manipulation, does it seem useful to implement here as well?

The video you linked very clearly has the R and G values swapped. Is it possible your receiver is doing internal conversion from RGB data to GRB output, and is in fact expecting you to send data in RGB order? I'll double-check to make sure the reordering is happening correctly in CC.NET later as well, in case it is sending incorrectly.

And finally regarding horizontal/vertical layouts, this is something I was thinking about while implementing this new functionality, but was just holding off on until we could at least test the "horizontal" matrix outputs.

from colorchord.net.

How did guys fare with TPM2.net to WLED? What kind of packet count and frame rate could you achieve? I've been working on a buffering/smoothing algorithm for WLED to regularize the playback interval and take out WiFI network jitter. Works great on single packet UDP but my multi-packet attempts have been less fruitful. UDP packets go missing as I think it's not reading them fast enough. But TPM2.net also needs to catch all the packets to work reasonably well.

from colorchord.net.

Thanks. I’m hacking on the WLED side and wanted to hear experiences of people using TPM2 with it. The ESP microcontrollers can’t receive large UPD packets that fast without some very careful tuning I think. Far too easy to saturate with my Python sender at the moment! But if TPM2 is working well for people at good multi packet frame rates to WLED, that’s an indication I need to tighten my read loop.

from colorchord.net.

The only person I've heard from that tried TPM2.net with WLED from CC.NET is @qu4nt4r. I assume you're also aware of the maximum packet size limits on the ESP, which we ran into earlier in this GitHub issue. It sounded like TPM2.net was working OK for him, with fragmented and reasonably-fast packets, as seen in the video he posted.

from colorchord.net.