thanks for keeping the discussion out in the open. While I may sound challenging at times, clarifying my own thoughts on this has helped me already make some improvements to my own program - which over break I hope to get in a releasable state.
I definitely think the more open the better. We have quite a few talented people all trying to solve the same problems, and I fell we can all help each other develop better programs.
I know you are pretty wedded to the idea of this being an integrated component - but I would love to see xlights be a lean mean hardware interface/lighting network configuration layer, with an API, and your project (and mine, and prancer) be clients of that API that send lighting control data. I don't think I'm going to get very far with that suggestion though ;-)
Well we already have the library for controlling the lights. So its sort of an API.
This is definitely an interesting idea, I would be interested in hearing Matt's view on this.
If we did do something like this there are a few things to consider.
Should virtual channels still be integrated in to xlights? I would say yes because the mapping stile effects sequences.
Now lets say I make my own program separate of xlights, if I want to control lights with in side the sequencer, or I want to make a console then ether my program needs to be installed along side xlights and the the user needs to set up the proper dependencies.
Then what ever I develop will be done cross platform with wx widgets and C++
Now since a console or a sequencer will be separate exe's inside xlights does it really make the program have that much more wait on a system. The resources needed will depend on what programs you load.
I would be open to the idea of separating the programs, but I just want to make sure that it would truly make sense to do so.
IMHO abstracting a "virtual" channel to a single physical channel doesn't add enough value for the effort. Take an RGB node. This will always be constrained to 3 adjacent channels. So to map Red Green and Blue each to their own virtual channel seems expensive.
Instead abstracting the light entity with a "start channel" property would yield more return. This becomes the object which you attach sequencing events to, and can be "remapped" to a different start channel.
While I agree that for RGB nodes there needs to be some automation on the mappings / remapping, no one wants to do 6,000 channels by hand.
But if we make RGB nodes as part of the architecture of the program I fell we are making things less fixable. I know some people have RGBW Lights in there display. I have heard of some one doing RGBWY lights in there display. I have items of my display that are RGWC.
What if a node system comes out that has a different channels configuration then 123, 456, 789, and so on?
This is why I feel a channel should be a channel and a group makes up a device.
Do I understand that you mean to map things out like:
flood group
red group
red virtual channel
red physical channel
green group
green virtual channel
green physical channel
blue group
blue virtual channel
blue physical channel
I agree that a little extra work up front is often worth it - but I'm failing to see what each layer there gives you.
For an RGB flood there is not much it gives but lets look at a smart string mega tree
Group = the entire tree
group = one smart string
red group
all red virtual channel in the smart string
green group
all green virtual channel in the smart string
blue group
all blue virtual channel in the smart string
group = next smart string
red group
all red virtual channel in the smart string
green group
all green virtual channel in the smart string
blue group
all blue virtual channel in the smart string
Now you can assign commands to each smart string and to each node in the smart sting.
I have to get to a final I will type up more latter.