Are there any Xlights users here?

For full disclosure, this is my first month using WLED :slight_smile:

1 Like

To setup WLED to control a matrix, and have that matrix also usable in xLights, is definitely something that can be improved.

Wishing / Rant

Controllers would be able to provide JSON indicating relative layout of the pixels. This would allow a user to configure a prop and keep its configuration with the controller.

For example, WLED would generate JSON indicating "I have X channels to be controlled, exposed as four independent props. The first prop uses 50 RGB pixels (channels 0…149), and is a simple linear, equally-spaced strip. The second prop uses 256 RGB pixels (channels 150…917), and 2D matrix (options: start corner, horiz/vert, serpentine, transposed). The third prop is a 2D prop using 256 …, and its relative integer X/Y coordinates are [[array of x/y coords]]. The fourth prop is a 3D prop using 100 …, and its relative X/Y/Z coordinates are [[array of X/Y/Z coordinates]]. etc.

xLights in this dream world would then be able to take that information, and let you just drag the auto-generated prop around your virtual display.

It’s conceivable props would be sold with hard-coded prop information, and “just work” … but this is all still a dream.

However, there are two distinct parts, and the best place for support differs for each… The short answer is the engineer’s mantra. Take it one step at a time. Take a snapshot when you get something working, so you can easily revert changes. Here’s a rough outline and where to get support for each part.

Configure WLED First

For configuring WLED’s built-in matrix support and FX, this is a great place for support.

  1. Configure WLED colors. Verify red, green and blue are correct using solid FX.
  2. Configure pixel count. Verify all pixels lit, and that if set to one fewer, one pixel would be non-lit.
  3. Use “chase” FX or similar to see the “natural” order of pixels.
  4. Configure WLED matrix options, which allows WLED to hide the “natural” order of the pixel matrix.
  5. Lock down the WLED configuration, make backups, and don’t change it.

Configure xLights second

If you get stuck here, I’d recommend going to https://xlights.org/, and clicking the Zoom Meeting link. By showing your screen / panel via video, experts can easily help you troubleshoot.

  1. The screenshots above should help. Note that you probably want to add the matrix as a single model, not by adding ten individual strings.

  2. Here’s a screenshot of a 18x20 matrix that fills a “fake” window in my roofline:


    a. Because I use a single contiguous set of pixels, I set # of strings to 1.
    b. There are 360 total pixels in that one string.
    c. Each row has 18 pixels, so that’s what I put in “strands/string”.

  3. Verify solid colors match

  4. Create some sub-models for testing…
    a. Slightly below the “starting location”, there’s a “submodels” edit … click the grey ... icon to open the submodel editor.
    b. Click on Actions..., then Generate Slices...


    c. Give a friendly name to the submodel, choose vertical slices, select a equally-divisible count (even 2 would work… this is just to validate layout), and click OK
    image
    d. Repeat to also generate horizontal submodels.
    e. In my example, I’ve created 5 vertical submodels, and 2 horizontal. When I click on one, it shows where xLights thinks that portion should map to…

  5. Now create a short (30s?) sequence
    a. only the matrix model needs to be included
    b. Add a five-second metronome timing (5000ms)
    c. right-click the model, and choose “show strands”
    d. Add “ON” effect to each strand / submodel … choose color individually

  6. Preview (play) it in xLights so you’re sure of what you should see if everything’s correct.

  7. Play to the actual matrix, and see if it’s all lined up. Errors should be fairly self-describing (wrong corner, interlaced right/left, etc.)

NOTE: I don’t know if E1.31 / DDP is passed through WLED unmolested… this has changed over time. This is why it’s important to configure WLED first … it just avoid any question about whether a WLED config change causes xLights to need a config change. (Some controllers require such changes, maybe not WLED, but why risk it?)