Somewhat strange flat pixel tree working oddly

[k6ccc]

When you build a pixel tree - and I'm talking a flat tree, not a round or partially round tree - there are two broad choices.  Either build the tree so all the strings are the same length which results in the top of the tree being somewhat pointed because the strings closer to the center are more vertical and therefore not losing height due to the slope that the more outer strings have to take.  The wider the tree shape, the more pronounced this is.  Here is an example of a tree built this way.  If your browser does not display the photo, there is a direct link to it.

http://www.newburghlights.org/photos/2014_Top_of_strips.jpg

I have my tree fairly wide by most accounts (and want to keep it that way:

http://www.newburghlights.org/photos/2014_Pixel_Tree.jpg

The other major option is to build the tree with each row of pixels at the same height.  This means that every string has a slightly different length.  Obviously something that is fairly easy with pixels and impossible with strips.  This results in the top of the tree being flat.

The biggest advantage of the same length version is easier construction (and possible if using strips).  The downside is that straight lines from side to side do not show up as straight on the actual tree, and text takes a non straight path across the tree.  The biggest advantage of the same height version is text and straight lines come out straight, and the disadvantage harder construction since every string is custom length, and is impossible using strips.  The other one is that the same length version results in the top lights of the tree being nested up to the bottom side of the star - which I personally like.

I have always built my tree with the same length strings version, but every year I get annoyed at text reading strange and horizontal lines (especially near the top) being nothing like a straight line.  This year I am planning on a complete rebuild of the tree and aim to get the best of both methods.  The "main" part of the tree will have each string custom spaced so each row of the tree will be at the same height, but there will be extra pixels at the top to fill in the space below the star.  Here is an CAD drawing that shows what I'm talking about.  The row marked 1 on each side is the top row of the 100 pixel strings, and the six rows about that are the extras to fill in below the star.

http://www.newburghlights.org/images/2023_Pixel-tree-top_CAD.png

So today, I tried to preview that.  What I did was add 24 Tree Top props that has the extra 82 pixles.  They are set up as 24 strings that are 1 pixel at the edges and up to 6 pixels for the center two.  Each string is a separate prop, and there is a group with all 24 strings.  That group is in turn part of my "Almost Everything" group which is what is used for almost all sequencing in SuperStar. I am using the Custom arrangement in the Preview Editor to get The Tree Top group to map correctly into SuperStar.  Took a few tries, but eventually got it all dialed in.  I can make effects seamless move across the extra Tree Top and onto the tree itself, or across both at the same time.  Works perfectly in SuperStar.  Exit SuperStar and Sequencer does it's thing to import the SuperStar data.  Here's where it gets odd.  In sequencer, if I simply click once on the SuperStar effect, the visualization window correctly shows the effects.  However, if I play that time segment, only the tree proper plays.  The extra 82 pixels of the Tree Top group does not play.  I can post a couple video clips a little later (wife just called me to dinner)...

Any ideas?

 

Edited January 22, 2023 by k6ccc

[k6ccc]

Tried rebuilding the tree completely as 26 strings with between 100 and 106 pixels.  Again, adjusted settings in the custom arrangement for a group of the 26 strings, and then put this new group into my Almost Everything group that is used for SuperStar sequencing.  Slightly different results, but again it looks perfect in SuperStar and when selecting the effect in Sequencer, but when playing that time segment, it's completely different.

 

[k6ccc]

Finally got around to creating a crappy video showing the problem.

 

[Box on Rails]

Jim If I had to guess based on the information provided I would say it has to do with the prop definition. PM me the prop definition and I can look for any issues that might be the culprit. Also. Have you tried to use the custom prop builder. I have had similar issues with groups that contain several straight line props. The fix I found was creating a single prop with the custom layout spread sheet. I would lay it out by string/port. Each Port would be numbered in the spread sheet by string 1 to 150 the next port 1001 to 1150 the next port 2001 to 2150 and so on for every string/port. I only use 150 pixels per string with all LOR controllers. Plus you can use your CAD drawing as the reference picture to lay out the prop. I am always up to a challenge, I would love to take a crack at making this prop with the custom prop builder. just PM me the current prop definition file and the CAD picture of it. I don't use SS but the effect you created using SS can easily be created using Custom Motion Effects rows. I will be adding a 12 string CCR tree this year so I see what you are getting at with pixels verses strips. I am going to eventually convert the CCRs to pixels so I am defiantly following this thread. 

[k6ccc]

Not a bad suggestion to try using the custom layout.  The only requirement is that it absolutely MUST lay out in SuperStar as shown in the video in the "Almost Everything" group.  Else, I get to do massive resequencing...

I have virtually no experience using the custom prop builder.  I did use it in my first year with S5 for the lights on the eves (those were a rather strange layout at the time) and I was not happy with the results.  Ended up changing out the pixel controller from a SanDevices to a Falcon which allowed me to make the logical layout completely logical.

Happy to have you take a look at it.  Go to:  http://newburghlights.org/share/2023_Preview/

There are three previews.

2023 Pixel Tree only = Just the pixel tree as the 26 individual strings

2023-1 Christmas - COPY = The entire preview with the pixel tree as 26 individual strings

2023-1 Christmas = The either preview with the pixel tree as described in the first post

 

[rick gurnee]

Jim, I was able to recreate your problem using preview 2023-1 Christmas - COPY and have a couple of observations (neither of which solve your problem) and a question.  First, if you change the number of pixels in each string to 100 it works fine.  This is not a surprise and really doesn't help much.  Second if you go into Superstar from the Pixel Tree Strings group instead of the almost everything group it works fine.  Not sure what that means either.  Finally a question you might not be able to answer.  Have you tried plugging in the lights to see what they do?  Maybe it's just a software bug, but the lights actually perform correctly.

I'll keep playing with it to see it I can see anything, but it certainly looks like you have discovered a bug.

[k6ccc]

26 minutes ago, rick gurnee said:

Finally a question you might not be able to answer.  Have you tried plugging in the lights to see what they do?

I'll answer your last question first.  No, and I largely can't.  The 2022 tree is down, disassembled for storage, and put away.  Second is that the tree is being modified to add the top section this year and that construction has not been done yet - and not expected for at least several months.

29 minutes ago, rick gurnee said:

Jim, I was able to recreate your problem using preview 2023-1 Christmas - COPY and have a couple of observations (neither of which solve your problem) and a question.

Glad it's not just me!

30 minutes ago, rick gurnee said:

First, if you change the number of pixels in each string to 100 it works fine.

Yea, that is essentially what it has been for the last several years.

32 minutes ago, rick gurnee said:

Second if you go into Superstar from the Pixel Tree Strings group instead of the almost everything group it works fine. 

I made the same observation.  I also have no idea what it means...  However that would mean a complete change in how I sequence that would take many hundreds of hours to change existing sequences, and massively make future sequencing harder going forward.

 

[k6ccc]

8 hours ago, Box on Rails said:

Also. Have you tried to use the custom prop builder. I have had similar issues with groups that contain several straight line props.

Tried a custom prop layout, and it behaved the same way.  BTW, I tried the channel layout twice.  In the first version, I had the top pixel (first in each string) stagger the channel assignment such that the last pixel in each string was always pixel 106 (channels 316-318).  This is the way that the previews I posted earlier today are set up.  In the second version, the top pixel was always pixel 1, and the bottom varied from pixel 100 to pixel 106.  Did not make any difference.

I tried a workaround where I just made a standard tree of 26 strings with 106 pixels in each string.  That would mean that I would build the tree as originally proposed, and the unused pixels at the top of most of the strings would simply not light any actual lights - no problem at all to do with the Falcon controllers.  That worked even worse!  Again, it looked perfect in SuperStar and perfect in Sequencer when selecting the effect. But when playing the effect, it ended up with segments of all 26 strings moving back and forth - completely garbage.

 

[k6ccc]

One more followup.  All variants of my non-standard arrangement tree do work correctly if I just use a Motion Effects Row of just the tree, but not if that prop (or prop group for some of the arrangements) is part of the "Almost Everything" group.

My guess is that there is some significance to that - but not sure what..  More experimentation...

 

[Box on Rails]

1 hour ago, k6ccc said:

One more followup.  All variants of my non-standard arrangement tree do work correctly if I just use a Motion Effects Row of just the tree, but not if that prop (or prop group for some of the arrangements) is part of the "Almost Everything" group.

My guess is that there is some significance to that - but not sure what..  More experimentation...

First question. How do you have the "Almost Everything" group  arranged in the group definition? Is it "use Preview"?

Second. when you made the custom prop did you use the selection under shape titled "Custom". then select the "Custom Light Placement" tab. This brings up a spread sheet to Make the tree from scratch. was this how you made the custom tree props or did you use one of the 8 tree preset selection in the drop down tab?

[k6ccc]

1 hour ago, Box on Rails said:

First question. How do you have the "Almost Everything" group  arranged in the group definition? Is it "use Preview"?

It is set as a custom arrangement.  That allows me to very specifically have each prop located exactly where I want it on the SuperStar grid.

1 hour ago, Box on Rails said:

Second. when you made the custom prop did you use the selection under shape titled "Custom". then select the "Custom Light Placement" tab. This brings up a spread sheet to Make the tree from scratch. was this how you made the custom tree props or did you use one of the 8 tree preset selection in the drop down tab?

When I did build the tree using the Custom shape, then select the Custom Light Placement.  Thank  God that you can copy and paste the channel setting for all 2682 channels from an Excel spreadsheet!

Previously I had used the 90 degree tree pre-defined shape (closest there is to a flat tree).

 

[Box on Rails]

11 hours ago, k6ccc said:

It is set as a custom arrangement.  That allows me to very specifically have each prop located exactly where I want it on the SuperStar grid.

Sounds like you have tried everything. It must be in the grouping of the SS group. Is the SS group "Almost Everything" the same as an S6 group? Is it created in the S6 preview or in the SS program and then transferred to the S6 preview?

 

My SS experience goes way back to using it with S4. When I started using S5 I found the Motion effects generator was much more user friendly and had way more effects capability. With S5 and S6 I stopped using SS all together. but I have been updating the 60 CCR License every time I upgrade just in case. 

[k6ccc]

5 minutes ago, Box on Rails said:

Is the SS group "Almost Everything" the same as an S6 group? Is it created in the S6 preview or in the SS program and then transferred to the S6 preview?

The Almost Everything always has been created in the S5 and now S6 Preview Editor.

Yes, the almost everything group is the same other than changing the tree configuration.  Been sequencing with that arrangement since 2019 - did it differently when I first started with S5

7 minutes ago, Box on Rails said:

My SS experience goes way back to using it with S4. When I started using S5 I found the Motion effects generator was much more user friendly and had way more effects capability. With S5 and S6 I stopped using SS all together.

I've been using SuperStar since 2012 - S3.  I really like the level of control you get with SuperStar.  Because of the way I sequence, it would be FAR more difficult to make any extensive use of Motion Effects.  Currently the only thing that is sequenced in Motion Effects is my P5 and P10 matrix panels - and those are just text.  And the only reason those were originally done in Motion Effects is because there was no SuperStar license available that could handle the number of pixels.  That has changed, and I CAN sequence either the P5 or P10 matrix separately.  I did one part of one sequence on the P10 last year in SuperStar.  This year, the expectation is more of the matrix panels will be moved into SuperStar...

 

[rick gurnee]

OK, here's a strange twist.  I started with preview 2023-1 Christmas - COPY and was able to recreate your problem.  I then removed arches (left half) and arches (right half) from the almost everything group and the problem went away.  I then added the two arches members back into the group and the problem DID NOT occur!

I can't explain it, but you might try that.  I did a lot of experimenting before I zeroed in on the two arches members.

[k6ccc]

You did a lot of experimentation to find that one!  Let me explain something about the arches left and right half.  Those are the same arches that exist immediately above the left and right halves in the SuperStar grid.  Brian added a limited ability to have the same props show up in the grid arranged differently a few years ago, at my request.  I wonder what the relation is...

Hey @BrianBruderer Are you watching this thread?

 

[k6ccc]

I finally put some more experimentation into this and have some more information.  As previously noted, I sequence almost my entire show as one "Insert SuperStar Effect" using my "Almost Everything" group.  The Almost everything group has almost everything in my show in one group created as part of the Preview.  That preview uses a custom group layout which allows me to explicitly place each prop on the SuperStar grid.  This is VERY important or else props can move when props are moved or added, or subtracted - which completely messes up the sequencing in SuperStar.  Largely because of old history (size limitation of the grid), I have my pixel tree laying on it's side on the SuperStar grid.  This has not been a problem until trying to make this unusual tree arrangement.

Trying some more test previews.  First try was to make the tree vertical on the SuperStar grid.  That did not help.  Next was to reduce the max height of the tree to 100 pixels (at the middle and down to 94 at the edges).  Still did not work.

In all cases, if you just select the Almost Everything group in Sequencer, it displays correctly, but when you play it, it does not.  Note that it plays wrong differently with the 94 -100 pixel tall tree vs the 100 - 106 pixel tall tree.

I just does not want to play the odd shaped tree.