Messages

1

General Software / Re: Tesla Light Show: Custom Show Creation

« on: December 24, 2021, 05:59:56 PM »

Not sure if you've seen this, but Electrek is crediting Tesla for creating xLights:

https://electrek.co/2021/12/24/tesla-releases-rare-blog-v11-holiday-update-surprise-non-owners/

"But the feature is actually also available to non-Tesla vehicle owners as Tesla released it as a new open-source software called xLights. Anyone can use the feature to create a light show and upload it to their car."


Could you maybe clarify on the Github page that xLights was not created by you?

2

Enhancement Requests / Re: Ability to set a Group as a Start Channel

« on: December 17, 2021, 04:32:13 PM »

For some reason I cannot understand what in the heck is your problem as it seems like you like tto make things overly complicated and use complex words to describe a simple problem.  Why does each segment of icicles have a different IP address?  What controllers are you using?

I have 4 segments of icicle lights.  Each segment consists of at least two strands of icicle lights.  In my model I just total up the node count for each strand I have daisy chained together and call it 1 string with the total of all node.  Each segment is connected to a port on a Falcon F16v3.  No power injection.  In xlights I just drag them to the port I want using the visualizer and xlights takes care of all universes and channel addresses.  Very simple.  I do not sequence (no one would watch anything I could do) so I buy or use shared sequences.  All of those sequences basically just program to a group called icicles.  There is no programming done to a universe or a channel or a segment.  That is why I think you are just over complicating things.

The controllers are F16V3's and E682's but I cannot imagine any other type would make a difference.

As far as I can tell, you and I have a similar setup and design (at least in some cases), the only difference is you plug your 2 icicle strands into the same controller, and I plug them into 2 different controllers. As a result, our configuration in xLights shouldn't be THAT drastically apart, but it is.

NOTE: I say "2 strands", but in reality of course I don't just have 2 icicle strand per roof segment, I have up to 8 strands, 4 strands goes left and follows the same port-spanning as yours does, 4 strands goes right and does port spanning there. I'm saying "2 strands going to 2 controllers" as a (reduced) example, cause port spanning on consecutive ports of the same controller is simple enough not to have to bring up, and it just conflates the issue. The issue at hand is the controller split that happens between icicle strand number 4 and 5, which you don't have, but I do.

And I am specifically making my hardware configuration as simple as possible. I have two lines of controllers around my house at two levels, one every 10 to 15ft and each prop is simply being plugged into the closest controller. That's it. No power injection, no null pixels - each controller output drives 100 pixels or less (5v), all within 10ft of that controller. Multiplied by 25 controllers. My pixels are custom made by Ray to have 12ft lead wires in front of the first pixel that I just screw on a green plug and plug straight into the controllers. No soldering or connectors. As simple (and reliable) as it gets.


However, this simplicity of "always plug in within 10 ft" sometimes cause some props to be torn across two controllers. There's just no way around it. I have controllers splits across various icicles, rooflines, matrix, megatree, wall lines and window lines.

I could just say: "You just have to live with the consequences - nobody else in the world needs to split props across multiple controllers, so just do your own thing". Except... I know layouts from 2 other people pretty well, and both of them also have a prop split across 2 controllers. And Keith also did a YouTube video on how to split a prop across 2 controllers (which actually doesn't work due to an unrelated reason, but at least it shows there is a need). And I believe even Gilrock does it, he just thinks it's fine doing that type of configuration in the controllers instead of xLights.

You just do not understand how xlights work. Good luck to you, but I still have to many things to do with my own layout at this point in time to spend time trying to define your xlights layout.

I don't need help defining my xLights layout. I have a working layout. I'm trying to suggest an improvement to the product and the simple 2-prop example I listed above demonstrates the underlying issue.

If you think I don't know how xLights work, why don't you take the 2-controller 2-prop example above and show me where I'm wrong?

3

Enhancement Requests / Re: Ability to set a Group as a Start Channel

« on: December 16, 2021, 10:33:54 PM »

This whole thread confuses me.  I have 4 segments to my roof edge.  I have 4 gutter segments and 4 icicle segments.  There are two controllers involved.  One does the left side of my house and the other does the right side of my house.  I have no problems running sequnces that specify effects on my one group of icicles or one group of gutters.

So imagine your 4 roof segments in reality each consists out of 2 icicle strands next to each other (so there are 8 total fixtures using 8 output ports). Each roof segment has one icicle fixture going to a controller left, and one icicle fixture going to a controller right off that roof segment. (Times 4 roof segments, so 8 controllers). They form 1 continuous visual line per roof segment, but it uses two ports each.

Now add a C9 pixel roofline on top of those icicles that are also plugged into those same 8 controllers, similarly split into using 1 port of the controller left, and one port of the controller right of the roof segment.

How would you set this up?

And specifically, how would you set this up in a way that your roof segments consist out of exactly 1 icicle model, and 1 single line model per visual roof segment (which is the way your models are naturally set up today it sounds like), and that you're also left with only 2 controllers in xLights.

Try and see if you can set this up in xLights today and create correct controller mappings for it using only 2 controllers and 2 models (1 icicle + 1 single line) that gets plugged into 2 ports on each controllers. Feel free to add shadow models or groups to make the connections work, but the main "Default" preview of your Layout should contain 1 icicle + 1 single line that spans one of your roof segments (like you have today).

Note, this is a huge over-simplification of the problem of course but it illustrates it well enough. There are of course specific workarounds for it by breaking either the controller or the model abstraction as I mentioned earlier. The point is not to.

4

Enhancement Requests / Re: Ability to set a Group as a Start Channel

« on: December 16, 2021, 06:19:38 PM »

It does not require multicast I ran that way for years using unicast.

Can you post that configuration? I can't see how you can switch back and forth twice between two different unicast controllers using a flat set of universes without xLights breaking the run at the fixture boundary.

Not sure why you think I'm angry. I love xLights and have been using it for years - long before it had controller configuration support. I can't imagine using anything else or promoting anything else. I'm also not blocked on this - I know how to work around everything even if I have to do custom changes to the .fseq files. However, I would love to see the product becomes simple enough for someone like my dad to be able to set it up himself - currently I have to set up all his controllers over Zoom every year. And xlights is 95% there to having perfect model mapping ability, but the last 5% forms a rework cliff rather than a smooth transition to a slightly more advanced configuration.

If you think xLights is philosophically against ever in the future providing generic non-contiguous model mapping support, let me know, and I can just take my fseq remapping tool and polish it for other people to use. It's sad to have to use two tools for what would be such a simple addition, but if it needs to, that's fine. I'll still continue to love and promote xLights.

PS: I do not see any option in the Polyline to define the number of segments apart from drawing them by hand. What's the option called?

5

Enhancement Requests / Re: Ability to set a Group as a Start Channel

« on: December 16, 2021, 02:03:21 PM »

Two problems with that:

a) It requires your controllers to run in multicast mode, which gets interesting to manage network traffic if you have > 128 universes since you'll run into IGMP snooping limits. Also some controllers have limited support for multicast universes.
b) Let's say you you want to change the first prop in your display from e.g. 50 to 51 pixels. This will require reconfiguring 25 controllers by hand to shift down all the channels - literally hours of work for what should be a 1 minute fix.

Either way, it again changes the "Controllers" view in xLights to something that is not controllers. Or put another way, it acknowledges and provides the need for an abstraction layer between models and controllers, but throws the baby out with the bathwater.

BTW: "Individual Start Channels" similarly acknowledges a need for abstraction, but it's limited in functionality since it needs to line up with specific pixel numbers. Shadow groups would do everything "Individual Start Channels" can do today but is infinitely more flexible.

PS: A polyline is no simpler than individual icicles - you need to guesstimate where each segment starts and ends. If there was a way to simply specify the number of segments and have xLights evenly divide, sure, but there isn't. And with polyline you lose the ability to specify pixel starting location per segment.

6

Enhancement Requests / Re: Ability to set a Group as a Start Channel

« on: December 16, 2021, 02:27:12 AM »

This is much more fundamental than automatic controller setup. Let me give a concrete example:

Imagine a roofline and icicle mounted below each other on a single eave. 200 pixels each. Simple straight line.

BUT in reality each of them are split into 2 different fixture segments, with 100 pixels each side. The 2 left connectors are going to a controller on the LHS of the eave and 2 right connectors are going to a controller on the RHS off the eave (being 5v and all). So each controller has one each of a roofline segment and an icicle segment plugged into it. 4 ports total. Still simple enough.

HOWEVER, there is no way to map this into a set of 2 models and 2 controllers (or even universes in the old versions of xLights). You either need to break the controller abstraction, or break the model abstraction.

If you want to preserve models, then on the controller side, you'd need to pretend each fixture segment is an entire controller by itself and set them up this way:


Controllers:
Name           | Prot. | Address.    | Universe | Channels
Left Icicle    | E131. | 10.0.131.1  | 1        | 300 [1-300]
Right Icicle.  | E131. | 10.0.131.2  | 2        | 300 [301-600]
Left Roofline  | E131. | 10.0.131.1  | 3        | 300 [601-900]
Right Roofline | E131. | 10.0.131.2  | 4        | 300 [901-1200]

Models:
Icicle -> Start channel 1, Nodes: 200
Roofline -> Start channel 601, Nodes: 200


So the controller view loses all concepts of controller-ness and becomes a fixture fragment list instead. Instead of having 2 controllers, you now have 4 fixture fragments so you can flip-flop the IP addresses. But... technically it works (provided your controller has more Universes than Ports...).

I've done this in the past, but it's so complicated to track that I stopped doing this. Instead I now instead break the model abstraction. I would just physically draw each eave with 2 individual icicles models in a row and 2 roofline models in a row, and then do a group over each of them. e.g:


Controllers:
Name           | Prot. | Address.    | Universe | Channels
LHS Controller | E131. | 10.0.131.1  | 1-2       | 600 [1-600]
RHS Controller | E131. | 10.0.131.2  | 3-4       | 600 [601-1200]

Models:
Icicle 1 -> Start channel 1, Nodes: 300
Roofline 1 -> Start channel 301, Nodes: 300
Icicle 2 -> Start channel 601, Nodes: 300
Roofline 2 -> Start channel 901, Nodes: 300

Groups:
Icicle = Icicle 1 + Icicle 2
Roofline = Roofline 1 + Roofline 2


So now my controller view is accurate, but my model view is off in lala-land. But because of groups, at least I can choreograph against something as a unit.

But the problem comes in that you can't put groups on previews, only models. And you now can't just draw a single fixture between two points, you now need to fairly precisely space 2 fixture fragments evenly into a line. Painful to do in 2D, hair-pulling in 3D. But necessary because of Whole House effects. And in reality I have up to 8 connectors per fixture, not just 2. And then multiple that by dozens of fixtures, not just one.

Since the group is necessary anyway, it would be SO much simpler if on top of that group you can also use that group as a shadow model for a real model that you CAN use in preview. That changes the mapping into the following:


Controllers:
Name           | Prot. | Address.    | Universe | Channels
LHS Controller | E131. | 10.0.131.1  | 1-2       | 600 [1-600]
RHS Controller | E131. | 10.0.131.2  | 3-4       | 600 [601-1200]

Models (shadow):
Icicle 1 Shadow -> Start channel 1, Nodes: 300
Roofline 1  Shadow -> Start channel 301, Nodes: 300
Icicle 2  Shadow -> Start channel 601, Nodes: 300
Roofline 2  Shadow -> Start channel 901, Nodes: 300

Groups (shadow):
Icicle Shadow Group = Icicle 1 Shadow + Icicle 2  Shadow
Roofline Shadow Group = Roofline 1 Shadow + Roofline 2 Shadow

Models (real):
Icicle -> @Icicle Shadow Group:1
Roofline -> @Roofline Shadow Group:1


This results in two real controllers, and two real models that can be placed as single units.

This abstraction also simplifies MANY other scenarios. Clearly xLights have seen the value of the "Shadow model" abstraction since it explicitly already exists - but it currently is limited due to the contiguous channel requirement.

Note at no point does any of this imply automatic controller configuration. Sure, this will allows it as well, but the problem above doesn't change whether you configure the controllers manually or automatically.

7

Enhancement Requests / Re: Ability to set a Group as a Start Channel

« on: December 14, 2021, 10:57:47 PM »

If I?m reading this correct The main thing is you want all the auto controller output configuration to work.  Sometimes it?s easier to just manually setup the controller if you have special situations.  That how we used to do it for everything. The auto stuff is nice in some cases but hard to make it work for everything.  I manually configure half my controllers it?s pretty easy and a skill everyone should know since it helps know how to troubleshoot.

And FYI this is not a good place for bugs or requests GitHub is the right spot. Here they will be read and forgotten about.  In GitHub it will probably also be forgotten about but will still show up in the open list.

Auto controller output is one thing - and it's not just a matter of setting it up initially. I have 25 controllers and I have to sometimes swap a broken controller or chip - so it means I have to keep a separate Excel spreadsheet for all my controller configs, rather than being able to centralize it in xLights. And it's SO close - just missing a small thing. And sometimes because of the enforcement of contiguous channels, you have to redo an entire controller or even multiple controllers to fit one more strand of something in there.

Even if I do set up the controllers automatically (like I do right now), there are just certain things that can't be done in a natural model due to this "contiguous wiring" requirement. I can't draw icicles on my eaves the way they are visually presented because they're centrally wired - I have segments that has e.g. 4 icicles next to each other in a straight line. It's one roof segment but it has 4 controller connections.

Same with my roofline, matrix, megatree, minitrees etc.  Simple things like skipping over a pixel when wiring a snowflake because the spacing doesn't fit means you need to do a custom model, you can't just have a null pixel in the middle of a fixture.

The xLights 3D modeller is now so good - it's such a shame to have to construct its content based on controller connections instead of what you visually see. And it also means if you e.g. move e.g. one icicle to another controller because you want to fit another prop into the controller and the wiring doesn't fit to the further controller, but the icicle's does, you need to redo the model and split the icicle in two, even though you didn't change anything visually with it - you just plugged it into another controller, and now it no longer has contiguous channels. (True story).

There are many ways to break the split between the visual model and physical controller connections. Vixen 3 had one way, which I certainly didn't like but it did work. So not saying necessarily shadow models + groups is the one and only way to do this - something like a virtual controller can also accomplish the same.

Heck I wrote a tool that blacks out single-color broken pixels so they don't show up in the remaining wrong color (by modifying the .fseq). So pre-processing the fseq is another way to create an abstraction layer, but remapping channels this way means you can't test from xLights directly. (Also something that can be done easily using a shadow model group with a skipped channel in between).

But this lack of abstraction between the model and the physical connections has been the one thing over the past few years that have always been a little painful in xLights.

8

Enhancement Requests / Ability to set a Group as a Start Channel

« on: December 09, 2021, 09:06:21 PM »

Follow up from here as a formal request.
https://nutcracker123.com/forum/index.php?topic=8073.0

Currently there is no generic way to output a single model across discontiguous ports or controllers.

I have several cases where I need to split up props into unnatural models in xLights to make the outputs work.  e.g.
* I have 9 real icicle roof-lines, but I need to model it as 30 different icicles since they have 30 port connections that are not contiguous and can't be (spanning across multiple controllers).
* I have straight-line props that are centrally connected and going into 2 different directions so can't be contiguously mapped.
* I have zig-zag matrix segments with odd-numbered strands (so last strand of first and first strand of next one is wired in the same direction and break the zig-zag).
* I have a matrix & megatree that's connected across 3 and 4 controllers respectively (doesn't work with Auto Mapping - original issue above).

All of these require building unnatural partial models in xLights that are incredibly hard to work with in the visualizer - especially in 3D.

Shadow models doesn't help because it still requires contiguous channels - and so does Auto Layout. (See original issue above).

I presume it would be a very big undertaking to create an abstraction layer in xLights between props and models.


HOWEVER... if a model can be made to output to a group (which may in turn contain other models that are NOT contiguous or in-order) it would be able to solve all of my port mapping issue above. It will also support partial string reversal, null pixels in the middle of a prop, and cover a lot of the Falcon virtual port scenarios across all (and multiple) controllers.

9

Do You Need Help? Post it here / Re: Shadow model across controllers vs. Universe Fill-up

« on: December 08, 2021, 01:21:12 PM »

Personally I'd just configure the controllers manually.  I had to do that last night because the upload feature to a Kulp board just wouldn't work and I don't have time to figure out why.  Only took 2 minutes to manually setup the inputs and outputs on the controller.  It's especially easy for a megatree.

Yeah, I think I'll have to do that. It's just a bit of a pain if I want to change a global configuration or swap around controllers etc. I have 25 active controllers, and 7 of them now require hand setup.

I wouldn't mind spending a few hours once off to get it to be automatic from now on, but I can't see there being any way to do it.

Feature request?

10

Do You Need Help? Post it here / Re: Shadow model across controllers vs. Universe Fill-up

« on: December 08, 2021, 11:21:53 AM »

I haven't watched his video but it seems to me that shadow models should not be dropped onto a controller so they should not be subject to the auto-sizing.  Drop the real tree on the controller and just create the shadow models and define their start channel to create the shadow overlay.

If I drop the real tree on the controller, it tries to drop 64 ports onto a 16-port controllers with everything from port 17 onwards is marked as red. It also shows a Universe count of 38 on a controller that only supports 12 universes and the upload doesn't work.

Basically I just want any mechanism to automatically Upload Outputs to the megatree and matrix controllers when a model spans multiple controllers. The video described (incorrectly) how to do this with Shadow models, but any mechanism would do.

11

Do You Need Help? Post it here / Re: Shadow model across controllers vs. Universe Fill-up

« on: December 07, 2021, 09:14:34 PM »

Should be no harm in using a universe size other than 510 or 512 if your controller can handle it. So uncheck auto size, set the universe site accordingly and re-enable auto size. You have more universes but that doesnt matter.

The xLights auto-size only ever does 510-sized Universes on my controller (E682). The video I linked to is an F16V3 and also same thing.

My board doesn't handle a universe other than size 510, but xLights shouldn't need to fill out the full universe. If I Upload the outputs with the board set to 510, then change the size of the last channel to 210 by hand instead of autosize, everything works. But then I can't do an automatically upload anymore before reversing everything.

12

Do You Need Help? Post it here / Shadow model across controllers vs. Universe Fill-up

« on: December 07, 2021, 02:07:47 AM »

When you do an Auto Layout, XLights always fills up the last Universe of the controller so that it's an even 510, even if there are unused channels.

This causes a problem if you're trying to split a Matrix or Megatree across multiple controllers using shadow models.

e.g. I'm following Keith's video from here, but he has the same problem:
https://www.youtube.com/watch?v=VKSyxB14-SE

His MegaTree is set up to run from channel 1 to 9600. His left shadow tree is configured as 4800 channels on controller 1, and right shadow tree is configured as 4800 channels on controller 2.

However, the controller #1 last universe gets filled out to the nearest 510, so it isn't just 4800 channels, it gets 5100 channels (7:54 in the video) on each of the controllers.

So that means the first 5100 channels of the MegaTree maps to controller #1, (with the last 300 of those channels off in the phantom filled out universe that has no string mapping), and the remaining 4500 channels goes to controller 2 which means 300 channels are dark.

If you follow his instructions exactly, then at 8:28 instead of dropping effects on the shadow trees overall, you expand the two shadow trees in the sequencers and drop an effect on the individual strands then it becomes obvious. You'll notice there is a missing/skipped string between Tree Side 1 #16 and Tree Side 2 #1, and then Tree Side 2 # 16 never lights up.

Is there any way to make this actually work while remaining in Auto Size / Auto Layout mode?

13

Xlights Setup / Re: Is there a way between FPP/xLights to only use every second pixel on a MegaTree?

« on: May 18, 2021, 10:11:21 AM »

I've a tree with 60 legs /M. I just changed the number of nodes per string to 120 (from 240) and you get a 30 leds/meter tree.  By the way it looks great!  The controller most likey will not skip nodes.  but xlights will.

Jnealand idea will work but I think it may be a lot of effort.

If I do that I only see the first half of the LEDs turn on on the tree.

14

Xlights Setup / Is there a way between FPP/xLights to only use every second pixel on a MegaTree?

« on: May 16, 2021, 12:37:52 PM »

I have a 60 pixel/meter tree that I would like to see what it would look like if I rewire to 30 pixel/meter.  Just for a test.

Is there a way between xLights or FPP (or a controller?) to emulate it so that it outputs to only every second pixel? I know I can do grouping, but that's not quite the same.

15

Xlights Setup / Zig-zag-null Zig-Zag-null

« on: December 08, 2019, 10:04:13 AM »

Can I set up a tree using a combination of xLights and E682's to follow a pattern of:

• Zig: 17 pixels
• Zag: 17 pixels
• Null: 2 pixels
• Zig: 17 pixels
• Zag: 17 pixels
• Null: 2 pixels
• Zig: 17 pixels

The Zig and Zag part I can set up in the controller.

Not sure how to set up the nulls though? My controllers don't support Virtual strings and only allows nulls up front.

I know I can put 4 extra null pixels after the prop, then swap them into place inside the .fseq files itself, but just wondering if there is an easier way already.