Abstraction Ideas

[csf]

Tonight the fun of working on updating a grid based, has actually given me a pretty cool idea.... I think.... 

Originally my intention for xlights was to abstract channels in to groups.  Then  channels in a group can ether all do the same thing at the same time, or an effect can be applied to a group.

The first idea I came up with is should there be master groups that can contain sub groups in side of them? I think that may make for some clever grouping abilities, but may also cause more confusion to the user, since know you can have nested group, but can cut down on the total number of groups you need to create for your show.

Now comes for the bigger idea. Should groups be made up of channels or virtual channels?

Originally my idea was to make groups of channels, but I am starting to think virtual channels may be best.

The original idea would make things a pain quick if you wanted to swap the id of a channel in you show because you would need to update every group that uses that channel and re map it.

Now if we used virtual channels and then deiced you want to change the ID  all you would need to do is update the one virtual channel map and all the groups would update.

I know Cas mentioned some where that he was abstracting channels in Prancer and then seating them in vixen.

This leaves me wondering if I go with virtual channels if they should be part of the console or if they should be part of the xlights base. If we make them part of the bass it may force us to update the sequencer,will probably take a little longer to have done, and my make things a bit more complex for the user to set up at first, but I think the ability to change your channel mapping easily, would over all be a big plus.

If virtually channels are only for the console then it would only work for sequencers made in xlights.

If we make it part of the base then any sequence you use in xlights could be remapped.

[tpctech]

Cool project!  I would go with virtual channels.  I come the pro stage lighting world.  Most light consoles use "control" channels and then the actual "dimmer" (dmx address or Sacn) is "soft patched" to the control channel.  This makes it very fexible to have several dimmers on 1 control channel also if a dimmer channel would fail it is easy to make the "patch" to another dimmer channel.  I had a situaltion in my yard where I used to have C9's along my eaves.  I divided them on 2 circuits because of the load and fed them from both ends due to where to run the cords down.  I then patched them to different dimmer boxes on each end of the house.

KEN 

[sean815]

Im currently using another software product and I have remapped my controllers many different times. I think if you go virtual then it would be a benefit to the end user since it will be less complicated to remap.

[RJ]

This sounds much like what I was trying to explian to cas one night on teamspeak as how I felt things would need to get to at some point.

If you guys ever want to hear my ideas, not that I could do them.  Let me know and we could meet in teamspeak for a chat.

RJ

[csf]

tpctech I will definitely be interested in your feed back as we go along with this project.

I want to try and make this program more along the lines of the systems used to control profesional light shows. If there ideas are god enough to run and choreograph major live light shows, they should be good enough for our Christmas displays.

 Now granted the stuff I have worked with is probably far from the cutting edge of the pro stuff, but it has given me some good ideas so far to start from, such as groups of channels.


RJ I would definitely be interested in meeting with you in the chat to talk about your ideas.

[frankr]

This is a very good idea in my mind.

So if I understand this correctly you would have a separate location where channels are defined and mapped to controller/protocol etc.  Then your groups within the grid would be able to "map" multiple channels or even other groups to provide an inheritance feature.

In theory I should be able to then remap any channel in my show and not have to update the sequences at all.  They would automatically be using the new controller/protocol specified in my update map.

This would be huge!  One of the biggest challenges I face year over year as my display evolves is that I either have to use the exact same channels for the same purpose year in year out or I have to painstakingly update every sequence with the new channel mappings. (not that any of this is difficult but it is time consuming and time is money/ more new sequences).

So on the RGB side of things are you planning for groups?  I.e. IF I have one group that includes a VC (virtual channel) and is currently set to all red and another group with the same VC included set to all green how would I know about this conflict?

I think at some level you need to have a grid that shows what the given VC would look like at any time on the grid.  The inheritance ability is very powerfuil but it would also be very easy to have your VCs unintentionally doing strange things.

One last note for clarity.  A VC would be symbolic name with an associated protocol and its relevant details I.e. Prot/universe/channel (where DMX is the protocol)

So "RGB Mini tree" could be mapped to say DMX/1/channels 17-19 OR LOR/10-12/1 (three controllers channel 1 on each controller) OR LOR/1/1-3

Make sense?

Frank

[castortiu]

I’m having troubles to understand what is the meaning that you give to a Virtual Channel, may be is something similar to what I’m doing.

I didn’t want to introduce VC to users since the term might sound confusing, for me the user works with “string of lights” and objects which have channels then later at some stage the user maps this to “physical channels”; in the current version of Prancer every sequence has a mapping from channels to Physical Channels (LE channel, SSR channels, etc).

The mapping can be redone at any time just double clicking on the object and map to a new Physical Channel(s).

But I found out there was a problem when I changed the location of some physical LE’s or starting address where I had to go to every sequence and update the mapping from the channel to the physical channel in every sequence.

So in my case there is already a work in progress where I do not store anymore the mapping for the channels on the sequences files (.prancer), instead every sequence .prancer uses a mapping file .prcmap where it stores the channels mapped to physical channels.

So the mapping editor manage how the channels will be mapped and updating the mapping automatically updates all the sequences, it divide and conquer the problem in two, create sequences independently from the hardware and then later the user works on the mapping, I think makes the user life easier.

If I understand properly what you mean the concept of virtual channels is similar, where you have VC which the users uses and map to the devices channels.

But thinking as a user, he’s not working in the screen with virtual channels, the object like a minitree may contain 3 real channels RGB and they are not virtual since they user can plug them and make them red, green or blue, so in my case I don’t have VC, I let the user work with “channels” and then later in the game when the user want to associate this to the physical devices then I expose the mapping from channels to physical channels.

Let me know if this makes sense to you.

Cas.

[ptone]

The original idea would make things a pain quick if you wanted to swap the id of a channel in you show because you would need to update every group that uses that channel and re map it.

This is only a pain if your groups explicitly reference channels - which would mean you are not sufficiently abstracting your lights.

I think the sweet spot here is to think about what it is one sequences.  I don't sequence channels, I sequence items in my display - this might be a window frame, a mini-tree, a mega-tree etc.

These might be be composed of many lights and many channels.

At a low level, there will always be channels - real channels or "physical channels"

Also at a low level, a single physical light might use one or more than one channel (an RGB pixel node, or a 16ch DMX fixture)

This low level association between a fixture and real channels is something that can't be abstracted - but from that point forward, this direct association should never be assumed by other features of the software.

so in pseudo code (though not far from they way my software works):

left_window = channel 2
right_window = channel 3

windows = group(left_window,right_window)

The windows group doesn't know anything about the channels used by the left or right window


Now I currently take it a step farther, I map a signal to a light or group.  The signal could be any number of inputs, the computer keyboard, a MIDI keyboard, a 3D intersection in Kinect, the tilt of an iPhone etc.

The signal is received and dispatched according to a mapping.  A given signal can be dispatched to one or more items.

So lets say I map the "R" key to the windows group.

dispatcher.add_observer("R", windows)

now I tap out a bunch of window flashes using the R key to my song.  I have a signal track.

I have a "sequence" that only consists of a set of signals.  This is completely abstracted from the groups, which are abstracted from the channels.

Now if I decide to add a roofline to be in sync with the windows, I can go back later and do:

eve1 = channel 9
eve2 = channel 10
eve3 = channel 11

eves = group(eve1, eve2, eve3)

dispatcher.add_observer("R",eves)

Now without changing the "sequence" (the signal sequence) at all, I can change how the lights map to it.  I can add or remove lights from groups, change some effects etc, without changing the sequence at all.

The signal only provides basic timing info.  The "show" part comes from properties of the lights, groupings, sequences and effects that these signals trigger.  You can experiment with all of the effects parameters etc without needing to change the sequence.

This object oriented approach is mapped directly onto Python's own object oriented language constructs, which provides lots of flexibility in creating a show.

-Preston

[csf]

Thanks for the feed back.

I came in to a bit of a road block in mapping out ideas. Well maybe a road block is a bit strong but it's definitely is giving me some pretty key things to think over.

Right now I have a pretty good map out of how channels and groups should work for the majority of shows, giving the most flexibility.

The road block has to do with the best way to map out massive RGB things like a smart string mega trees, or a smart string matrix.

My current design would work fine if it was only one strip of RGB lights, such as a cosmic color ribbon. The issue comes in to play when you make two rgb strings and want them to work in unison with each other, to do things like map out words or designs.

This leaves me with two options that I see:
1) Make a matrix editor for dealing with these more complex mapping needs
2) Keep rethinking the design and see if I can work in support for matrix type display elements from the beginning.

castortiu or ptone have ether of you given thought to matrix mapping display elements by any chance?

[ptone]

My current design would work fine if it was only one strip of RGB lights, such as a cosmic color ribbon. The issue comes in to play when you make two rgb strings and want them to work in unison with each other, to do things like map out words or designs.

This leaves me with two options that I see:
1) Make a matrix editor for dealing with these more complex mapping needs
2) Keep rethinking the design and see if I can work in support for matrix type display elements from the beginning.

castortiu or ptone have ether of you given thought to matrix mapping display elements by any chance?

are you saying it would work for a ribbon but not matrix because you are limited to a 1D array concept.

I'm not sure if you might be underestimating the scope and size of the project you are tossing around.  Things like "make a matrix editor" involve a substantial amount of coding.  What tasks would you accomplish in a matrix editor?  What would the UI be?  How would you apply effects?

for the record - I'm not a huge fan of overdoing the matrix concept:

You are not allowed to view links. Register or Login

That being said - I do think matrix like arrays mapped onto structures are interesting - and posted some example of what an RGB megatree setup might look like in my software:

You are not allowed to view links. Register or Login

the "tree_string_sequence" is an example of a complex (rising wave spiral) effect done procedurally.

many advanced 3d modelers will still write texture and shaders as "procedural routines", the idea is you achieve an effect my manipulating each light in some way over time.  I know this is not a point and click interface - I don't think it is easy to do sophisticated things through a simple to use UI.

In general in my package, you organize individual lights into higher level things - and then apply the effects to those higher level things in a way which trickles down to the individual lights.

So if I were to tackle the problem of a matrix with my current design it would be something like:

define all the pixels in a matrix
"shape" them into a 2D array datastructure (rows x columns)

take an input image (could be a frame of video) and downsample to my array size - that is, downsample a 640x480 image into a 60x40 pixel array.  Sample each downsampled value for color and intensity - then set these values for each pixel.

it would look roughly something like:

pixel=[]
for i in range (1,(60*40),3)
   pixel = NewPixel(start_channel = i)
   pixels.append(pixel)

matrix = array(pixels)
matrix.reshape(60,40)

matrix.map_image("foo.jpg")


Because my runloop (the "show object") simply checks with each light for its channel data each time through the runloop - the higher level managers (such as the above that maps an image to an array of pixels) just set state of the lights, and doesn't worry about sending anything out on the channels, it stays high level.

-Preston

[rrowan]

Hi Csf,

For a SS mega tree

You have your SS_Mega_Tree() top level and somewhere lower down you have SS_Mega_Tree_1(), SS_Mega_Tree_2(),  SS_Mega_Tree_3(),  SS_Mega_Tree_4(),  etc which would need to know the number of SS and number of nodes per

Just ask the user how many SSC they have and number of nodes per SSC so your have your array

A standard Mega_Tree would have one dimension array Mega_tree()

Just my 2 cents

Rick R.

[csf]

ptone while the projector art is rather cool I know for the things I would like to make a projector just would not give the effect I am looking for.

My plan for Halloween next year would be to make a 40 by 32 light matrix using smart strings and then I want to display animated pumpkin faces on it. The key is I want to pumpkin to be made up out of lights, not animated images. I fell if all I was going to make is images then might as well just make a video.

It may be cool if some one made a program that projected images that looked like light bulbs and could be synced to music. But that's an entirely different program from these that we are making.

But lets not make this in to a matrix debate.

I do like you guys suggestions. I am starting to think the key may not be so much to rethink the groups but re think the way effects are applied to groups. I already have one idea in mind that I think my be a good solution, but want to think it out a bit more.


Basically originally the effect would tell the group what to do. I am thinking now to make it that a group is just a block of information and the effect it's self tells the program what to do with / to that block of information.

[frankr]

csf

Not sure I understood that parting shot there.

A full blown Matrix editor may be extremely complicated coding but I am wondering if something similar to what KC has done with the LED TRIKS interface in Vixen could be a model to follow?   I think we need to understand what use models you want to create with the matrix editor to understand the complixity of it.

I.e. frame by frame editing of the matrix with definition of time between frames, though I am not sure I have seen how you intend to handle timing yet.

If we added the ability to easily specify what the pixel layout and the associated channels are then this could be a powerful interface for creating sequences like you want .  I can see this working well for any type of layout. I.e. Mega tree, straight matrix etc...

Frank

[csf]

I may be missing some thing but a basic matrix editor should not be  to bad to code.

Basically you need a time line of frames (each farm can be set for a time amount like a gif animation)

Then you would have a grid determined by the size of your matrix. Each grid cell can be one sold color. Each grid cell represents one light. The program then maps the color value to the correct lighting control value needed for that cell on the grid in that frame.

Then to take it to the next level you can have layers of shapes with key frame animations.

Honestly I think a matrix editor would be simpler the an all out sequencer. But for right now I want to concentrate of getting a sequencer working.

Right now my new way on mapping channels / groups  / effects I fell will be very powerful for a sequencer.   I just need to figure out the ideas for how the grid would work for sequencing from a coding prospective. Right now it would require that each cell's width is independent of the width of the other cells in the grid. Now this ether leaves me with making each track (row)it's own grid, or I need to code up a custom grid drawing routine (which will probably add quite a bit to development time then). Right now I want to research grid options and see if there are any open source code that may help with the grid and save me from having to do it all by hand. 

[ptone]

Basically originally the effect would tell the group what to do. I am thinking now to make it that a group is just a block of information and the effect it's self tells the program what to do with / to that block of information.

Yes - this is similar to what I have.  I basically divide things into two types, things that need to know about time, and those that don't.  Something that needs to know about time has an "update" function and gets added to the show.

So a basic "Group" (which can be nested in my software), is just a collection object.  When you tell the group to trigger, it just triggers all its "elements" (I use elements throughout my software as the term for sub-items).  A basic group doesn't need an update func, because the elements of the group, once triggered, take care of themselves.

An effect is a subclass of a group that has an update function that handles how that effect is managed over time.

For example, I wrote a "Lightening" effect yesterday for the school play I'm doing the lighting for. This has certain lights as elements, and when the effect is triggered it starts an algorithm to determine a random set of lightening flashes, and fires those lights off.

Some other effects I'll write are strobe and pulse (basically a strobe with curves).  These will have parameters like:

duration on, frequency
sync_elements or randomize etc

Just for demonstration (and to verify that I'm talking about in production software, not theory) here is my lightening effect:

You are not allowed to view links. Register or Login

Code: You are not allowed to view links. Register or Login

from lights import *
import random

class Lightening(LightGroup):
   
    def __init__(self, *args, **kwargs):
        super(Lightening, self).__init__(*args, **kwargs)
        self.macro_next = 0
        self.micro_next = 0
        self.intensity = 0
        self.flashing = False
        self.bout = False
        self.flash_count = 3
   
    def update(self,show):
        if self.intensity:
            if not self.macro_next:
                self.macro_next = show.timecode
            if not self.micro_next:
                self.micro_next = show.timecode
            if self.macro_next <= show.timecode:
                if not self.bout:
                    # flash a random number of times
                    self.flash_count = random.randint(3,6)
                    self.bout = True
                elif self.flash_count == 0:
                    self.macro_next = show.timecode + random.randint(7,14)
                    self.bout = False
                    return
                # we are in for a bout
                if self.bout and self.micro_next <=show.timecode:
                    if self.flashing:
                        # trigger is on superclass
                        self.trigger(0)
                        self.flashing = False
                        self.flash_count -= 1
                        self.micro_next = show.timecode + 1.0 / random.randint(5,25)
                    else:
                        intensity = random.randint(100,255)
                        self.trigger(intensity)
                        self.flashing = True
                        self.micro_next = show.timecode + .04
            else:
                # wait
                return


    def signal(self,message):
        """receive a midi message and trigger"""
        vel = message[0][2]
        self.intensity = (vel*2)
        if not self.intensity:
            if self.flashing:
                self.trigger(0)
                self.flashing = False
            if self.bout:
                self.bout = False
            self.macro_next = 0
            self.micro_next = 0



Right now my new way on mapping channels / groups  / effects I fell will be very powerful for a sequencer.   I just need to figure out the ideas for how the grid would work for sequencing from a coding prospective. Right now it would require that each cell's width is independent of the width of the other cells in the grid. Now this ether leaves me with making each track (row)it's own grid, or I need to code up a custom grid drawing routine (which will probably add quite a bit to development time then). Right now I want to research grid options and see if there are any open source code that may help with the grid and save me from having to do it all by hand. 

So in your GUI - what does a "track" represent - is it a group, an effect, both.  Do you end up with the same information represented in the grid twice if it is used in more than one group/effect?  Is there any abstraction between channels and groups, that is, in my system channels are lumped first into LightElements which are the hardware specific groupings of channels, and then LightElements are put into LightGroups and LightSequences (which I will probably rename LightChase)

-Preston