Need Help With VIZ and SS element ordering

[bob_moody]

VIZ ver 3.11.2

SS ver 40_CCR ver 0.1409.30 (Yes .. real version ... debug version from Brian...)

 

I'm still running what I guess would be "old school" in regards to Viz and SuperStar. To create pixel elements I create them as CCR elements, import them from VIZ to SS, create the sequences and export them to LOR Sequence editor. I have a program that I wrote last year that takes out the macros. In sequence editor I keep both the CCR ver (this allows me to view the sequence in viz) and the DMX version until I have everything the way I want it then delete the CCR element leaving the DMX element reducing the overhead of elements that don't really exist.

 

That being said, I'm creating a new layout for the front porch that includes pixels on the roof line, pixels on the window frames and pixels on the porch support poles (think Belagio poles...). The caveat is the pixels being used. I came across a truck load of GECE pixels. They work well.. they are a little slow. The biggest drawback to them is the pixel addressing (6 bit addressing means only 64 pixels in a single string.  The GECE's are being used for the roof line and windows. The Belagio poles are Coro project (think Holiday Coro CoroCanes without a hook ... using 2811 rectangular pixels)

 

I created a VIZ that, from the top, down, contain the roof line, the 3 windows and the 5 Belagio poles.

With the CCR Draw Wizard:

The roof line is a single line of pixels built from single of 50 pixles and a second line of 14.

The 3 windows are built from 1 frame with 26 pixels, and 2 frames each with 18 pixels.

The Belagio poles are 25 pixels each.

Here is my issue. When I imported this layout, the 3 windows came out as the first row (also note the windows start with pixel 1 in the upper right hand corner. Additionally the first window frame is correctly ordered, the smaller 2nd and 3rd frames while on the same row seem to be ordered from pixel 18 to pixel 1 (backwards). The second row is the roof line (should be the first but the order and layout are correct. Finally the Belagio poles are ordered correctly from a pixel standpoint 1 is top, 25 is bottom the programming order is backwards. The first pole on the left is pole 5 and should be pole 1. Each of the Belagio poles are showing up on their own grid row.

I think I have encountered ordering issue before but Brian usually just did the Voodoo that he do... so well!!! and poof all was good .. I'm hoping someone can help me sort the Viz to SS issue out...

attached is a screen shot of the viz. I can provide screen shots of SS and I can provide the VIZ and SS files if needed.

What I would like to happen is for the roofline to the be 1st row, each of the 3 windows on their own row and in the right pixel order and for the left Belagio pole to be #1 etc ...

I appreciate the help ...

Bob

Edited July 31, 2015 by bob_moody

[BrianBruderer]

For the strings on your windows that are on the grid going the wrong direction, bring up the Fixture dialog box for that string and add the keyword "superstar reverse". Note that if you have S4 you don't need the keywords anymore, there is a "superstar" button in the fixture dialog box that has all the options in it that you can do with the keywords. It makes it easier so you don't have to remember the keywords. But the keywords are still supported for backward compatibility.

 

As for the poles not being on the rows you want, be sure you have set "Max Length" for the sequencing grid to be long enough for all the poles to fit. Otherwise I'm not sure why they are not being ordered in a logical way. You can email the visualization to brian@superstarlights.com and this time instead of doing it for you, I will tell you what to do so that you will know what to do in the future.

[bob_moody]

Brian,

thank you.. I will send over the file ...

I added the superstar reverse keyword to window 2 and window 3..it resolves the issue .. just really curious as to why it reversed them in the first place.

What I'm getting when I import is 7 rows in the grid .

The first row are the windows.. all three of them..

The second row is the roof line. I would have expected it to be the 1st row.. other than that its working as desired.

The third thru seventh row are the poles. Whats odd is that the right most pole is on row three... would have expected it to be the left pole

Also, regarding the windows. I'm curious as to why they didn't break out into rows as well.. I was expecting to see 9 rows total...

The Viz file will follow shortly...

Thank you for continued support Brian.. I really appreciate it..

Bob ..

The poles are correct in pixel order. That is to say, pixel one is at the top, pixel 25 is at the bottom.

[BrianBruderer]

If superstar thinks something is a matrix it puts all the matrix things at the bottom. For some reason it thinks the roof line is a matrix and puts it towards the bottom. The fix is to add the keyword "superstar nomatrix" to the prop containing the Roofline.

 

As for the order of the poles, I know it is confusing, but realize that I have to allow for importing the visualization with a horizontal grid or a vertical grid. And I want the horizontal grid to be the same as the vertical grid except that it is rotated counter-clockwise 90 degrees. Conversely, if you rotate the horizontal grid 90 degrees clockwise then you get the vertical grid.

 

So in your case if you had imported with a vertical sequencing grid then the poles would be expected to be in order on the grid from left to right. Rotate that counterclockwise to get the horizontal one and the first pole is on the bottom. This means that you should think of the bottom row as being row #1 and the top row is the last row.

 

I'm not sure if that all made sense, but I want the vertical and horizontal grid to be the same except rotated so that after sequencing it, you could import the other way and the sequence would not change.

 

As for why some windows needed to be reversed and some not, it is because superstar tries to make the pixels go from left to right, and well, it does what it does. And my problem is that I can't "fix" it at this point because I need it to import the same for backward compatibility, that is, everybody's visualizations need to keep importing the same way they do.

 

I tried to make the importing be "automatic" and arrange things in a logical way, but in many cases it does not. I would like to come up with a new system that people can use that is independent of the old system. But that will have to happen next year.