Ability to set a Group as a Start Channel

[deonb]

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.

[Gilrock]

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.

[deonb]

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.

[Gilrock]

Sounds like you are letting your desire to use auto controller setup control you and causes all this pain.  Go back to the way we used xLights before it managed controllers.  We used to advertise it as a benefit because all xLights did was use the models to create a huge chunk of data and then you just had to configure in the controller what data you wanted on each output.  I kinda liked it that way and I warned them this quest to have all the controller stuff automatic was going to end up making the program more complicated.  xLights can be completely abstracted away from the physical hardware.  You can still operate that way but you won't get automatic controller setup.

[deonb]

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.

[Gilrock]

I don?t think you get how I?m saying it could work. For controllers just create one dummy controller with a million channels.  Then just map universe and channel numbers to the starting model for each real controller and daisy chain the rest of the models so your not defining all the start channels just the first model on each real controller.  Then in the real controllers define each output to the universe channel it needs to be.  Controller?s can be mapped to anywhere.  Also sounds like you aren?t using the Polyline model to do icicles where it?s pretty each to define each section and then map that section to its own universe/channel.

[deonb]

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.

[Gilrock]

It does not require multicast I ran that way for years using unicast. And all this talk about abstraction I?m sorry but you can?t have it both ways.  You either have to define all the details for the controllers and how the models map to them in xLights or in the controllers.  I do a mixture of both.  And you really should learn more before you get bent out of shape about what the program can?t do.  Polyline has two odes it will divide the pixels along the segments for you or you check a box and do it manually.  You just seem angry and I?m done interacting it?s Christmas chill out.

[deonb]

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?

[jnealand]

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.

[deonb]

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.

[jnealand]

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.  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.

[deonb]

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?