Can't select different smart receiver types for different strings when more than 4 ports.

[thekameleon]

NOTE: IF YOU DO NOT ATTACH A SEQUENCE THAT DEMONSTRATES YOUR PROBLEM THEN THERE IS A HIGH PROBABILITY YOUR ISSUE WILL JUST BE CLOSED AND NOT INVESTIGATED.

Describe the bug
I have a model that is 6 strings. I am using a Kulp 8. I want the model to start on port 9 and go through port 14 (6 ports). I want ports 9 through 12 to be a Fpp_v2 smart receiver and 13 through 14 as Falcon_v1. the problem is, it appears wants to keep the model all on the same smart receiver type.

To Reproduce
Steps to reproduce the behavior:
(and/or link to a short video showing the problem with audio track describing what you are doing)

1. Take a model with 6 ports
2. put it on port 9
3. specify a smart receiver type for port 9
4. go to port 13 and try to specify a different smart receiver type

Expected behavior
I would expect to be able to specify a smart receiver type for a group of four ports independent of how many ports a model uses.

Versions (please complete the following information):

• OS: Windows 11
• xLights version 2024.19

[merryoncherry]

Without regard to the validity of the request... can you just run these receivers as dumb receivers to get around your problem in the short term? Unless you are chaining receivers on the same port, there's no reason they have to be in smart mode.

[thekameleon]

I was planning on using more models, and hoping that o could use a smart receiver on B. The other work around is break the model up with shadow models. I figure though that you guys would actually want to fix the issue Yahoo Mail: Search, Organize, Conquer On Sun, Dec 22, 2024 at 21:59, ***@***.***> wrote: Without regard to the validity of the request... can you just run these receivers as dumb receivers to get around your problem in the short term? Unless you are chaining receivers on the same port, there's no reason they have to be in smart mode. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[computergeek1507]

its not a simple issue to fix, that same problem occurs when trying to span a model between local ports and smart receivers. You can use shadow models or set the V2 receiver into V1 mode as well.

[thekameleon]

I never suggested it's an easy fix. And yes, things can be worked around, but I almost have as many shadow models as I do models dealing with these work arounds. It might be a thought to enhance the visualizer feature to make things a little more robust. Again I'd take a crack at it, but I know you keep your devs on a tight leash. Yahoo Mail: Search, Organize, Conquer On Mon, Dec 23, 2024 at 0:10, Scott ***@***.***> wrote: its not a simple issue to fix, that same problem occurs when trying to span a model between local ports and smart receivers. You can use shadow models or set the V2 receiver into V1 mode as well. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[derwin12]

Coding - the key here is the model properties. There is one spot for controller, one spot for port and one spot for remote. Everything after is automagic. It would need to be some big/multi valued setup to allow who knows what combination of smart/normal/none configurations. Then you need to figure out the visualizer part. Ugh.

[thekameleon]

That sounds right to me. I think it would be better if the port, smart receiver type were stored at the string level. Since really a controller doesn't care about a model, but it does care about a string. This would at some point allow for for just assigning a string to whatever port and receiver type you want.  In my use cases it would completely remove the need for shadow models, and simplify my user experience. Yahoo Mail: Search, Organize, Conquer On Mon, Dec 23, 2024 at 8:52, ***@***.***> wrote: Coding - the key here is the model properties. There is one spot for controller, one spot for port and one spot for remote. Everything after is automagic. It would need to be some big/multi valued setup to allow who knows what combination of smart/normal/none configurations. Then you need to figure out the visualizer part. Ugh. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[cybercop23]

I was planning on using more models, and hoping that o could use a smart receiver on B.

If you plan to use B for other models... hy can't you first move the 2 extra strings from 13-14 to 9-12B and run your chain that way? Yes you may run into the same issue later once you max out (if you care) the pixels/port @40fps, but seems like that will be the proper next step.
You shouldn't need shadow mondels for all.. only for one that's the od ball and ALSO.. contrary to pupular believe, you don't need congruent shadow models.. most of the time you can get away with 2... and just use strings to separate them..

There has been some discussions to allow each string of a model to be individually placed in Viz, but that's a large overhall and that will solve this.. so any changes will be more foreward looking and total rework, vs fixing/patching odd-ball setups.

[thekameleon]

That's what I am hoping for is that this will be addressed in the future. I'm not looking for an immediate fix. Using shadow models is a work around. As for using the other ports like 9-12B, it's because I have other models on those and I am trying to manage to stay under the threshold for 40fps. Yahoo Mail: Search, Organize, Conquer On Thu, Dec 26, 2024 at 9:02, ***@***.***> wrote: I was planning on using more models, and hoping that o could use a smart receiver on B. If you plan to use B for other models... hy can't you first move the 2 extra strings from 13-14 to 9-12B and run your chain that way? Yes you may run into the same issue later once you max out (if you care) the pixels/port @40fps, but seems like that will be the proper next step. You shouldn't need shadow mondels for all.. only for one that's the od ball and ALSO.. contrary to pupular believe, you don't need congruent shadow models.. most of the time you can get away with 2... and just use strings to separate them.. There has been some discussions to allow each string of a model to be individually placed in Viz, but that's a large overhall and that will solve this.. so any changes will be more foreward looking and total rework, vs fixing/patching odd-ball setups. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>