Jump to content
Light-O-Rama Forums

Maximum number of channels on prop


Vfere863

Recommended Posts

Hi,

 

I have created a Mega Tree Prop that I have placed on a visualization. The prop contains 12 string of 24 RGB pixel lights. When I try to import it into Super Star I get a message stating that the maximum number of 64 channels for a prop has been exceeded.

 

Is this the max number of channels for a prop or is this due to my current license. I have the TWO CCR license.

 

Thanks,

Victor

 

Link to comment
Share on other sites

I did a 12 string, 50 pixel tree and it importer just fine. Did you create a prop for each string? If not, try grouping 24 or 48 pixels into a prop, then create a second prop just like the first one. Once you have them all created that way, try the import and see if SSE let's you do it

Link to comment
Share on other sites

Thanks for the responses.

 

I had to break up the full 12 string prop file into individual files for each string. After that was done I then pulled each one in the Visualizer and repositioned them. That was painful. Anyway I was then able to bring the file into SSE.

 

It would be nice if SSE could import any prop file regardless of the number of channels per prop cause the first file has a clean image of the mega tree while the one with the separate files is not as appealing.

 

Victor

Link to comment
Share on other sites

It is definitely not related to your license level. There is no limit to the number of channels in a prop, but there is a limit of 64 fixtures in a prop. But the visualizer does not allow adding more than 64 fixtures to a prop, so I'm not sure how you got more than 64 fixtures in the prop.

 

I am curious to see exactly how you are getting this error, if you can, email your visualization file to me at brian@superstarlights.com

 

The visualization file ends with .lee and will be located at:

c:\ <your lightorama folder> \ Visualizations \ Editor

Link to comment
Share on other sites

Sorry for the problems you had in importing the file. I would like to understand better the error you were getting. There is no channel limit per prop that I am aware of in the SuperStar software. Please email the visualation file that creates the error to brian@superstarlights.com

 

The visualization file ends with .lee and will be located at:

c:\ <your lightorama folder> \ Visualizations \ Editor

Link to comment
Share on other sites

Hi Brian,

 

To better describe the error I am getting it say 64 fixtures instead of 64 channels as I stated earlier.

As soon as I get home today I will mail you my visualization file.

 

I create this prop using an application I am creating to build LOR prop files. The file I will send has 3 universes each containing 504 channels for a total of 1512. I am able to create a blank background in the visualizer and import this prop, then run the visualizer and also a sequence in the sequencer and I see the lights on the prop reacting.

 

Let me know if you need anymore information on this.

 

Thanks,

Victor

Link to comment
Share on other sites

That explains it. As you say, there is a limit of 64 fixtures per prop. I have this limit because the visualizer only allows 64 fixtures per prop. Are you able to open this file in the Visualizer? I would expect that it gives you an error when you try to open it.

 

When I wrote the code I didn't think about the visualization being created in another tool. I suppose what you would like is to remove the limitation in SuperStar even if the visualization is not usable in the Visualizer, it could still be used to define the layout in SuperStar. Is that what you would like?

Link to comment
Share on other sites

Yes I am able to load it up in LOR Visualizer and run it, then start a sequence in LOR Sequencer and the lights do react in the visualization.

 

Yes if there was a way to import a file that contains props like the one I described that would be very useful in the whole sequencing experience. The ability to see how the sequence will look before exporting and then importing into the LOR sequencer would be a big plus.

 

Thanks,

Victor



 

 



 

Link to comment
Share on other sites

Thanks for emailing the visualization file. I opened it successfully in the Visualizer but if I double click on the Prop in the Prop list to bring up the Prop Properties dialog box the program hangs.

 

If I import it into SuperStar I get the warning saying the maximum number of 64 fixtures in a Prop has been exceeded and it only loads in the first 64 fixtures.

 

I could increase the array size for fixtures in a Prop, but there are other problems. Currently when you make a CCR/CCP/CCB mega tree in the Visualizer it creates a separate fixture for each CCR string and then places them all in a Prop. SuperStar is coded around this design. That is, it determines the strands in a megatree by looking at each fixture in the Prop. So it means that SuperStar puts the pixels in a particular strand in one sequencing row, then it puts the pixels in the next strand on the next sequencing row. And it relies on each strand being in a different prop.

 

In the case of third party RGB lights, each pixel has to be created as a separate fixture. The expected way to organize them is to place each string in a separate Prop. If you do that, SuperStar will place the pixels in each prop in its own sequencing row. Note that the default length of a sequencing row is 50. If your RGB strings are more than 50 pixels then you must increase the "Max Length" of the sequencing rows, this is done in the "Import Visualization" dialog box.

 

I realize that it would be desirable for the code to look at the layout of the pixels and lay them out in a logical manner regardless of how they are placed into props. But currently the code does not do that. It is a much more difficult task than it seems, so the code relies on each strand bing in a separate fixture in the case of CCRs/CCBs/CCPs and in the case of third party RGB lights it relies on each strand being in a separate Prop.

 

Also, I am hesitant to increase the limit of 64 fixtures in a Prop unless the Visualizer increases the limit also and allows you to open up the Prop Properties dialog box for the Prop.

Link to comment
Share on other sites

Thanks for the reply Brian.

 

I did as I said earlier create 24 individual prop files with the proper pixel/channel assignments to mimic my mega tree. I then pull each file into a visualization and had to position them so they took on the look of a mega tree.

 

Once I had that .lee file I an able to load it into SS and the program sequences correctly. I can't export due to my current license level. This is where I am going to be making my decision shortly.

 

As far as editing the prop file in the visualizer I am still figuring out the meaning of the XML elements in the prop file. I believe that is where I may have so work to do. For now if I don't edit the prop once it is loaded I can see what I have sequenced. I am using xligths 2012e to get the mega tree sequences right now.

 

I really hope that LOR begins to provide a way to manage and create these types of props. This seems to be the way the community is going.

 

Thanks,

Victor

Link to comment
Share on other sites

  • 2 weeks later...
  • 4 months later...

/disclaimer/

the purpose of this post to to document how I worked around the limitations of visualizer/props/fixtures issues:

 

This post is a work in progress and my intention to update as I learn and go along.

 

I had an interesting challenge with my RGB pixels.

I will post more about this later (I'm house-sitting and not at my LOR computer this week)

 

As mentioned earlier,  the visualizer and also apparently SS has a limit of 64 fixtures per prop.

 

My eves have pixels running along all sections with string lengths of 149, 128, and 91 RGB pixels. Additionally I also have a RGB pixel tree (which uses 88 pixels.  this is a 8 - Branch 'not-so mega tree' with each vertical arm having 11 pixels)

Because of the 64 fixture limitation, the 149 pixel string is broken up into 5 segments, the 128 is broken into 3 segments, and the 91 is broken into 3 segments. For the most part they also represent the changes in direction/slope of my eves.

I had two major challenges:

1.) the Prop limitation of 64 fixtures.

2.) the way SS arranges the "grid" for the pixels.

 

When the SS imports the visualization is "scans" horizontally across the screen using using the number of lines indicated in the import dialogue box.

So whatever props are intersected by the line are included on that particular "grid line"

 

my problem I was using a photo of my house to develop my visualizer. And when looking the a-frames of my eves ended up overlapping, and the grid that sequencer made up what really worthless.  Since my eves are not a single continuous prop (due to the 64 fixture limitation)  sometimes the string would be split so that each segment was on a separate grid line.  This would make morphs impossible to sequence. So basically SS was making a grid that was not useful at all.  (not everyone make a simple tree or a matrix with pixels).

 

[placeholder for photo to come next week]

 

The 1st thing that helped was un-selecting "scrunch grid" box

2nd thing that helped was increasing the grid length to match the length of the longest string

 

then once i figured out how SS was reading the visualizer... and how it does't use the photo in visualizer.. it dawned on me that I don't need to keep the segments in their "reality location".

 

So here's what I did:

 

I saved another version of my visualizer file, and removed EVERYTHING except the RGB Pixel props. (i have 48 regular LOR channels for regular light strings) took them out... it was just clutter anyways. 

next I separated each Eve string vertically such that no string overlapped if you draw a horizontal line across the screen.  

(this included my not-so mega tree)

 

 

so basically I separated my major elements into 4 vertical groups... Upper Eve,  Roof, Lower Eve, not-so mega tree
 

[picture to come next week]

 

Now grid was starting to make sense.

The top line of the grid is now 91 boxes (representing the upper eve)

the 2nd line of the grid is now 128 boxes  (representing the Roof line)

the 3rd line of the grid is now 149 boxes (representing the lower eve)

and the 4th line of the grid is 88 boxes. (representing the "not-so" mega tree)

 

This setup works really well for the eves

now I can easily do morphs and stuff for the eves and its working well because they are represented horizontally in the grid, and that how they work in real life.

 

but it's not so great for the "not-so mega tree" which is mostly functions in a 2-D world both horizontally  and vertically
I suppose I could split the tree in to 8 different vertical elements (increasing the entire vertical lines to a total of 11) but then the it would not be represented as a tree anymore but as a bunch of vertical lines.

[picture to come next week]

Edited by Crazydave
Link to comment
Share on other sites

Crazydave,what I do is sequence my Pixel tree separate from the other pixels. I then save that file and export. Now, leaving all effects, morphs in the sequence, I import another visualization, and either modify, change or delete the effects. This way, my timings are perfect because they are exactly like the first. I go through each song 5 times like this, each time with a different element. The last thing I sequence is the LED Mega tree. Once all of the sequences are complete and exported, I put them in the main channel config. Now I have a sequence that all elements are in perfect time with each other.

Link to comment
Share on other sites

/disclaimer/

the purpose of this post to to document how I worked around the limitations of visualizer/props/fixtures issues:

 

This post is a work in progress and my intention to update as I learn and go along.

 

I had an interesting challenge with my RGB pixels.

I will post more about this later (I'm house-sitting and not at my LOR computer this week)

 

As mentioned earlier,  the visualizer and also apparently SS has a limit of 64 fixtures per prop.

 

My eves have pixels running along all sections with string lengths of 149, 128, and 91 RGB pixels. Additionally I also have a RGB pixel tree (which uses 88 pixels.  this is a 8 - Branch 'not-so mega tree' with each vertical arm having 11 pixels)

Because of the 64 fixture limitation, the 149 pixel string is broken up into 5 segments, the 128 is broken into 3 segments, and the 91 is broken into 3 segments. For the most part they also represent the changes in direction/slope of my eves.

I had two major challenges:

1.) the Prop limitation of 64 fixtures.

2.) the way SS arranges the "grid" for the pixels.

 

When the SS imports the visualization is "scans" horizontally across the screen using using the number of lines indicated in the import dialogue box.

So whatever props are intersected by the line are included on that particular "grid line"

 

my problem I was using a photo of my house to develop my visualizer.

 

https://docs.google.com/file/d/0B0xdJRFwbuXXWjZnNldRZGlJc1E/edit?usp=sharing

 

which made  totally worthless grid of this:

 

https://docs.google.com/file/d/0B0xdJRFwbuXXM1AxbW91LWxNN0E/edit?usp=sharing

 

And when looking the a-frames of my eves ended up overlapping, and the grid that sequencer made up what really worthless.  Since my eves are not a single continuous prop (due to the 64 fixture limitation)  sometimes the string would be split so that each segment was on a separate grid line.  This would make morphs impossible to sequence. So basically SS was making a grid that was not useful at all.  (not everyone make a simple tree or a matrix with pixels).

 

https://docs.google.com/file/d/0B0xdJRFwbuXXVXRtanQzOUtGRGs/edit?usp=sharing

 

 

The 1st thing that helped was un-selecting "scrunch grid" box

2nd thing that helped was increasing the grid length to match the length of the longest string

 

then once i figured out how SS was reading the visualizer... and how it does't use the photo in visualizer.. it dawned on me that I don't need to keep the segments in their "reality location".

 

So here's what I did:

 

I saved another version of my visualizer file, and removed EVERYTHING except the RGB Pixel props. (i have 48 regular LOR channels for regular light strings) took them out... it was just clutter anyways. 

 

next I separated each Eve string vertically such that no string overlapped if you draw a horizontal line across the screen.  

(this included my not-so mega tree)

 

so basically I separated my major elements into 4 vertical groups... Upper Eve,  Roof, Lower Eve, not-so mega tree

So I simplified it to :

 

 

https://docs.google.com/file/d/0B0xdJRFwbuXXVlA0T29yTHg3a00/edit?usp=sharing

 

Now grid was starting to make sense.

The top line of the grid is now 91 boxes (representing the upper eve)

the 2nd line of the grid is now 128 boxes  (representing the Roof line)

the 3rd line of the grid is now 149 boxes (representing the lower eve)

and the 4th line of the grid is 88 boxes. (representing the "not-so" mega tree)

 

This setup works really well for the eves

now I can easily do morphs and stuff for the eves and its working well because they are represented horizontally in the grid, and that how they work in real life.

 

but it's not so great for the "not-so mega tree" which is mostly functions in a 2-D world both horizontally  and vertically

So what I did now was re-organized how I made the mega tree into horizontal props instead of vertical: and then I made each horizontal element equally spaced. so the SSS would pick it up nice.

 

So then instead of have the "not-so" mega tree organized vertically, I rearranged each prop  so they were  horizontal string instead of veritcal.   This makes it easy to sequence since now every prop in the SS and Visualizer is now horizontal.

https://docs.google.com/file/d/0B0xdJRFwbuXXVXRtanQzOUtGRGs/edit?usp=sharing

 

But this gave me the problem of unused grid section on the top half of the grid....   How do I get rid of this?


https://docs.google.com/file/d/0B0xdJRFwbuXXVmRNSDlCb1V5MEk/edit?usp=sharing
 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...