Individual Start Nodes for Native Models

[cybercop23]

I started to take a look at this and have some of the skeleton (albeith copy/paste from the Custom Model) done for Circle, Matrix and Star. TBH I think those are the most that folks use, maybe Arches with the new FanArch, but we can easily add it to that as well.

The issue seems to be related to the fact that today, we have # of String and Nodes/Strings that folks can use if/when they are even. That doesn't work with the current Custom Model logic, where the total number of nodes comes from the model itself.
So the idea is to add another option that will be migrated during the upgrade to take the current stand*nodes into a new Total Nodes and going forward, any new definition will be done with Total Nodes - that way you can have uneven/untied strings -> ports.

Any other ideas, suggestions and/or things to consider (we'll handle the new xml format for the new option... :) )

RE: #2334 #2466 #3148

[AzGilrock]

I remember Keith and I talking about it a couple years ago. I thought it needs to be done at the model level instead of hacking Individual start channel code into every individual model.

[AzGilrock]

You guys really need to just coach the new folks not build stupid props. If they model things in xLights first they won't run into any problem configurations. We've done without the feature for 10 years no rush to stuff it in unless its done right.

[AzGilrock]

Are you done with the XmlSerializer stuff? I'd like to see that finished first so I can move to the next step of removing the XML from everywhere else.

[cybercop23]

Part of that is that props aren't made exactly to fix the specs so even if they do it first in xLights they will still need to manage it with custom model or shadow. It's not really how long we've done it without, is the new HD props and most specifically new folks coming into the hobby that have no ideas.

I have a Draf PR for all that I have thus far. I'm trying to figure out how to get to the model groups themselves so I can pull the parms and also for submodels. I got the lists of groups and submodels and can itterate through them and they are in the output, but now I need to get to each individually to pull more info.
TBH I thought this custom start nodes would be a slam-dunk. I worked on it a long time ago before I could compile and thougth ... "hey now I can actually do it, let me try it" until I started and then realized the darn total nodes vs string * nodes/sting will be an issue.

[AzGilrock]

Seems to me like we need a better way to map the channels of a model into controllers. We should be able to de-couple that and a model could theoretically be defined as one string with 1000 nodes and then a controller mapping could be defined that says which node maps to each output instead of saying that # of strings in a model has to equate to number of outputs on a controller.

[AzGilrock]

That's why I don't want to rush this and add a bunch more XML into all the models and then wish we didn't have the mess we end up with.

[keithsw1111]

Lets be careful we dont end up with the vixen complexity. They did exactly what Gil seems to be hinting at and it makes using Vixen exceptionally hard ... not easier. My view is we take any change like this extremely slowly as this could f**k up a hell of a lot of code including all of the auto layout code.

Fundamentally autolayout and upload is a reward for having a layout compatible with it. While i also want and have largely built it to a point where almost anything could work with it it was never a requirement to have everything work with it. Having edge cases which dont work with it is ok.

[cybercop23]

Of course... don't want to break anything. Thinking maybe doing it one model at a time may also help with this. I have the circle model almost done. Did some hard coding to bypass one issue I'm stuck on and check all render styles gor groups, model and sub-models. Happy to report, they all match against 2024.9. So looks promising.

The Nodes[x] that's a NodesBaseClass object gets set with the wrong StringNum at the wrong index; using the old logic. I can fix it in the Cirlce Model since it overrides the ActChan (why???) and gets called last, but I'm thinking it may be best to figure out why the buffer gets set with the "wrong" StringNum in the first place. Can't seem to find where it gets the initial StringNum value... any suggestions where to look? Would very much appreciate it. Sitting in Zoom and chasing this darn thing...

[cybercop23]

Yeay... found it.. digging...

[cybercop23]

Okay.. I have this working for both Circle and Star without adding any new parms and it can freely move between old version w/o support custom node support and the new version that supports defining start nodes.
Well... this is almost true... I can't seems to find where/how the String[x] parm that's used in CustomModel gets stripped when used elsewhere. Right now I call them Strings vs String, but if someone has an idea where that code is I can try to get it updated so net/net there are no new parms added to the RGBEffects file (just using what's aleady there, albeit Circle/Star will pick up the String[x] parm (I don't need the CustomStrings=1).