Author Topic: New Software  (Read 13665 times)

Offline frankr

  • Sr. Member
  • ****
  • Posts: 347
    • Rocklin Lights
Re: New Software
« Reply #45 on: December 15, 2010, »
Hey csf,

I think we need to see some architectural representations of what you are thinking in order to see if we can get started on breaking this up into pieces.  Do you have a high level design sketch or an object model in mind? Are you planning on doing some inheritance in the object model to define different but derived objects?  If we can get on the same page about these types of things then I would be glad to pick something up and start coding.

The challenges is we need to have some coherent design to march to so that we can make sure we are coding towards the end goal.

just my $.02

I will note that most of my experience is  in embedded systems using C and a RTOS so I am not the best person to be giving OO advice...

I should be able to put in some good time on coding in the next two weeks or so if there is a design that I can focus on.

Frank

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #46 on: December 16, 2010, »
I just sent this to Frank in response to an email he sent me, but I think it may help give some of the tech people in our community a better idea of what I am trying to accomplish, so I will post it here too.

Right now Xlights suports Networks, Each network has a type, port number, bud rate, an number of channels.

Virtual channels will build on top of networks. It will assign physical channels to virtual channels, which will be used in side the program. This will allow users to remap the channel used inside the sequences to there physical channel in there display set up. Basically no more having to worry abut plunging things in to the wrong channels on set up. Also lets say a channel goes bad in your show, all you would have to do is remap to a free chanels and you would be good to go.

A virtual channel object would look some thing like this

channel Id = unique integer used internally inside the program for identifying the virtual channel
channel name = string user can create to identify channel inside groups
Network type = integer that corresponds to net work number set up previously.
channel number = integer that represents what channel in the network the virtual channel is.

Then there will be two types of groups.

Groups of channel objects.
For RGB lighting you can assign a color to one of these groups.

Groups of Groups.

So for an RGB flood light you can asinine one virtual channel to red, one to green, and one to blue. Then assign all three groups to a group of groups. (now I will admit this may seam like a bit of extra work for a single flood but for RGB pixel nodes, or light matrices, I think the extra set up work is the best way to go, epically since we can automate some of the set up work)

Now you have effects.

Originally I was thinking that effects pass parameters back to groups and the groups do there work. This Idea was created to keep effect scripts easier for users to create.

Right now effects have switched to having a group passed over to the effect and the effect processing the group data and telling the program what to do. This should allow for much more powerful effects, and will eliminate the issues my original idea ran in to when dealing with smart string mega tress or light matrix. Basically the original concept failed when it wen it went in to two dimensions. So for now I have decided that effects will all be hard coded in to the program, until I can come up with a good way to integrate the effects with a scripting language. 

The one issue that I can see right now is what exactly does the effect tell the program? This I fell depends on if your ruining a live show from like a console or a scheduled show. If its a live show the program may well just pass the commands right to the light controller dll. If the show is going to be shown in the future I see storing all the actual lighting commands needed (to there virtual channels) to a 2demensional array where each row is a virtual channel and each column is a time in which the commands change. So I think efects should send the data to a special class / function that will minipulate the data as neded depending on if the show is live or being scheduled.

Right now there are 4 pieces to xlights.

menu = sets up networks
scheduler = runs shows
tester = test networks and hardware
library for controlling lights.

Virtual channels will be part of menu

My original idea was to add two more programs
Console  = run a live light show, create groups, create effects
Sequencer = organize groups and effects on a time line set to music

At this time I am wondering if with the change in effects if it may be worth just crating every thing in side the sequencer and maybe make a console at a latter time when the sequencer is complete, instead of making the console first.
 
So right now if I wanted to turn group one on I would do this

Pass group1 to effect on, effect on will give the commands to the method for determining what to do with the comands, if its in save mode it will just store the commands in the array I described above, if its in live mode, it will read the data of that virtual channel, then read the network data for that channel and pass the corect comand to the light library and the lights will respond to the command.

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Re: New Software
« Reply #47 on: December 16, 2010, »
You are not allowed to view links. Register or Login
I just sent this to Frank in response to an email he sent me, but I think it may help give some of the tech people in our community a better idea of what I am trying to accomplish, so I will post it here too.

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.

You are not allowed to view links. Register or Login
Right now Xlights suports Networks, Each network has a type, port number, bud rate, an number of channels.

Virtual channels will build on top of networks. It will assign physical channels to virtual channels, which will be used in side the program. This will allow users to remap the channel used inside the sequences to there physical channel in there display set up. Basically no more having to worry abut plunging things in to the wrong channels on set up. Also lets say a channel goes bad in your show, all you would have to do is remap to a free chanels and you would be good to go.

A virtual channel object would look some thing like this

channel Id = unique integer used internally inside the program for identifying the virtual channel
channel name = string user can create to identify channel inside groups
Network type = integer that corresponds to net work number set up previously.
channel number = integer that represents what channel in the network the virtual channel is.


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. 

You are not allowed to view links. Register or Login
Then there will be two types of groups.

Groups of channel objects.
For RGB lighting you can assign a color to one of these groups.

Groups of Groups.

So for an RGB flood light you can asinine one virtual channel to red, one to green, and one to blue. Then assign all three groups to a group of groups. (now I will admit this may seam like a bit of extra work for a single flood but for RGB pixel nodes, or light matrices, I think the extra set up work is the best way to go, epically since we can automate some of the set up work)
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.

You are not allowed to view links. Register or Login
Now you have effects.

Originally I was thinking that effects pass parameters back to groups and the groups do there work. This Idea was created to keep effect scripts easier for users to create.

Right now effects have switched to having a group passed over to the effect and the effect processing the group data and telling the program what to do. This should allow for much more powerful effects, and will eliminate the issues my original idea ran in to when dealing with smart string mega tress or light matrix. Basically the original concept failed when it wen it went in to two dimensions. So for now I have decided that effects will all be hard coded in to the program, until I can come up with a good way to integrate the effects with a scripting language. 

The one issue that I can see right now is what exactly does the effect tell the program?

I'm assuming your program will have a runloop of some sort.  The question you will have to answer is who is responsible for ultimately determining a channel value.  Is it the virtual channel group, or the effect.  If the latter, the problem is managing the handoff of "ownership" of the virtual channel between effects, or between effects and a bare virtual channel.  I'd argue that it should be the thing that is closer to the virtual channel.  In this case an effect acts as a choreographer.  This also allows effects to be overlaid and use different blending styles (ala photoshop).  I'm working on a demo of some new features in my code that allows this overlay.  For example you can have a "pulse" effects (ramp up and down in intensity, color etc) a strobe effect applied simultaneously.  So you have a light that is dimming in a pulse, changing hue in a pulse, and flickering all at the same time.  In such a scenario no one effect can tell the channel what to do, but each can "alter" various properties for an element (with a blend mode), and the runloop cycles through each element asking for their channel values.

You are not allowed to view links. Register or Login
This I fell depends on if your ruining a live show from like a console or a scheduled show. If its a live show the program may well just pass the commands right to the light controller dll. If the show is going to be shown in the future I see storing all the actual lighting commands needed (to there virtual channels) to a 2demensional array where each row is a virtual channel and each column is a time in which the commands change. So I think efects should send the data to a special class / function that will minipulate the data as neded depending on if the show is live or being scheduled.


You might be interested in this thread where we are talking about the pros/cons of vixen as a universal interchange format:

You are not allowed to view links. Register or Login

You are not allowed to view links. Register or Login
Right now there are 4 pieces to xlights.

menu = sets up networks
scheduler = runs shows
tester = test networks and hardware
library for controlling lights.

Virtual channels will be part of menu

My original idea was to add two more programs
Console  = run a live light show, create groups, create effects
Sequencer = organize groups and effects on a time line set to music

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 ;-)

 
You are not allowed to view links. Register or Login
So right now if I wanted to turn group one on I would do this

Pass group1 to effect on, effect on will give the commands to the method for determining what to do with the comands, if its in save mode it will just store the commands in the array I described above, if its in live mode, it will read the data of that virtual channel, then read the network data for that channel and pass the corect comand to the light library and the lights will respond to the command.

that's a lot of commands ;-)

I'm not entirely sure, but I think the bit about "give the commands to the method for determining what to do with the comands" implies a certain amount of abstraction of the triggering event.  I went ahead and banged out this schematic of how my program is involved - briefly:

events are what drive the show.  These events are either trigger events (which consist of a on and off time and an intensity) and map events (which can be wired up to various properties).  Events control elements.  These elements may be a single light element, or a group, or chase etc (effects are not shown here, but they would basically be elements as well).  The element is then responsible for determining what the value of each of its channels should be.

The idea is to have the events layer be general and expressive of the timing.  The elements handle the complexity of translating that into raw channel data.

-Preston
--
budding channel wrangler

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #48 on: December 16, 2010, »
Quote
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.

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

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

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

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #49 on: December 16, 2010, »
I think I hit basically every thing major before now that I look it back over.

Another idea is we can see what software ptone creates. We can see how much work it would take to get it working with xlights and to be cross platform, and then take it from there trying to create an interface for it and so on.

This could be a viable option as long as ptone is okay with the idea, and the program will function in a way we can build off of.

Then again if we do create a mix of xlights and ptone somewhere does it become its own separate program? Guess it depends on if there are so many changes that it will slow down xlights or the core of ptone software, which would then make it better being it's own thing.

Overall there are allot of unknowns but it may be worth something to consider.

I think the first thing we need to figure out is will xlights just be for light control or will it have every thing in it needed to make a show.

Maybe we should schedule a chat to talk about these ideas.
« Last Edit: December 16, 2010, by csf »

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Re: New Software
« Reply #50 on: December 17, 2010, »
You are not allowed to view links. Register or Login
I think I hit basically every thing major before now that I look it back over.

Another idea is we can see what software ptone creates. We can see how much work it would take to get it working with xlights and to be cross platform, and then take it from there trying to create an interface for it and so on.

This could be a viable option as long as ptone is okay with the idea, and the program will function in a way we can build off of.

It's too early to say - but I think the challenge of new sequencing software will require several different approaches for different audiences.  Cas said he wants Prancer to be good for the average Joe running on windows gear.  I'd say my primary target user is me ;-)  (and others who might think like me) and I'm trying to come up with some neat layers that sit between a trigger, and a bunch of channels.

I'm sure either a web front end (for local or remote use) or a wxPython UI could be grafted on at some point, but I would want to get the core right first.

I spent a little time trying to learn the internals of xLights - and I still think a great area of focus for the project would be to take the bulk of xlights_out.cpp and wrap it into a libxlights library that could be linked to from other software, or be used in dynamic language bindings.

Having this idea of a rosetta stone library I think is very appealing, and is something any sequencing or light control software project of the future could make use of.  xLights would then use this libxlights library itself much the way it uses xlights_out.cpp internally and statically to provide a timing UI etc.  But people might come up with other scheduling or testing UIs that take advantage of the core lib.

You are not allowed to view links. Register or Login

I think the first thing we need to figure out is will xlights just be for light control or will it have every thing in it needed to make a show.


IMHO - the best things are those that focus on a limited domain, and do it very well.  When something tries to include everything and the kitchen sink - it feels bloated, confusing and ineffective.

-Preston
--
budding channel wrangler