Prop design problem using Lines-Connected

[Brad Stucky]

Could someone verify this?  When you create a pixel prop using the Lines-Connected shape, check the location of the blue dot on the prop created.  If you make the prop and select Starting location to be left, the prop appears on the the design screen with the blue dot (indicating starting point) on the right.  This also doesn't correspond to the layout view which says it's on the left.  Somehow, this caused problems for me this year.

[Jimehc]

you can have the Blue Dot (Input Connector) on either end - and tell then string that Pixel 1 (start location) is left or right...  so you can have connector Blue Dot on Right side, yet have actual Pixel 1 on left side ( String Reversed)

If both are on same side then flip the string in your Preview.... Hope that I did not add to the confusion..

[Brad Stucky]

1 hour ago, Jimehc said:

you can have the Blue Dot (Input Connector) on either end - and tell then string that Pixel 1 (start location) is left or right...  so you can have connector Blue Dot on Right side, yet have actual Pixel 1 on left side ( String Reversed)

If both are on same side then flip the string in your Preview.... Hope that I did not add to the confusion..

Thanks for responding so quickly.  I'm still sorting this out in my mind as I type here.   So the pixel number placement is fixed upon generation of the prop and can only be affected by editing the starting location, no matter what the rotation of the prop on the preview screen.  So then the  rotation or relocation of the blue dot only affects the playback on the preview, but not the actual display?  If that's the case, then a person needs to be make sure that the location of the blue dot matches the actual pixel placement so that playback of their props and the preview screen will match.  I have 2 pixel line props that feed from the left and 2 that feed from the right.  Unfortunately, when I created them in the preview, I selected feed from the right on all of them and when I later corrected that,....   well, anyhow,  I think I've got it now and that seems to make sense.   Thanks a bunch and Merry Christmas, Jimehc

[Jimehc]

36 minutes ago, Brad Stucky said:

I have 2 pixel line props that feed from the left and 2 that feed from the right.

So in your Preview that i how the lines are draw two (Blue Dots) feeding from the left and two (Blue Dots) feeding from the right - but the Start Location for Pixel 1 is left...

First, In your Preview you rotate the line to get proper Input End Location...

Second, In the Prop Definition you set the Pixel 1 Start Location

Edited December 22, 2022 by Jimehc

[Brad Stucky]

That's it.  I played around a bit more and found that if the preview prop is flipped,  the existing motion effect in my testing sequence is now reversed, even though the pixel layout position remains unchanged since I didn't change the starting location.  The problem came about when I adjusted the starting pixel location, I forgot to adjust the blue dot location on the preview to match.  I believe this is the first year that I created new props where I had to later make adjustments in the wiring for the pixel order and since my sequences were already created, the programming looked correct on the preview, but was not at the actual props.   When I noticed that my props weren't playing in the correct direction, I remember the wiring change and made the proper adjustments to the starting location, but I neglected the location of the blue dot on the preview props and wondered why my preview and actual props were still not playing in the same direction.  I guess I assumed that the location of the blue dot was actually tied to the physical placement of the first pixel itself.  A person wouldn't notice anything to the contrary until they rotate a prop in the preview and checked playback.   I believe (but haven't verified) that when most of the built in props are created, the blue dot is automatically placed at the correct starting location matching the drop-down box selection, but for Lines-Connected, this isn't the case.  I'm guessing this isn't really an issue since there are obviously props made using this shape that need to be rotated in order to fit design.   I now vaguely recall a similar issue many years ago with a LOR color ribbon prop in a vertical position.   I bet this was the same issue since it, too, was a Lines-Connected prop but I somehow managed to correct the problem without fully understanding the situation.  I'm still learning, I guess. I hope others can learn from this as well.  Thanks again.    

Edited December 22, 2022 by Brad Stucky
spelling

[k6ccc]

Very important key point.  You can build your actual props almost any way that you want.  However, what's in the Preview must match the actual props.  That includes the starting location - both the description and the blue dot in the visual display part of Preview Editor.

 

 

[Brad Stucky]

Whoops!  Sorry, I thought I was done, but try enabling channel level programming.   I did this from scratch with (2) 50 pixel Connected lines, one fed from the right and one fed from the left.   They are lined up in the preview screen, end to end so that both feeds are in the center of the preview  with the channel numbers increasing outward to each side of the preview window.   After making sure that the blue dot is also located toward the center for each line prop, I saved and exited the preview creation section and created a test sequence using this preview, I checked motion effects and they seemed to function correctly (can't verify actual pixel props since the show is presently running), but when I enable channel level programming for both and create a chase from the first pixel in a test sequence,  one of the chases progresses outward (the one fed from the left progressing to the right) but the line that is fed from the right, progressing to the left side is lighting up at the left end of the prop and chasing inward.  I double-clicked on the "first" channel pixel of each line prop on the sequencer page and the prop definition page opens showing that the pixel is given channel 1 in both cases, but that isn't correct for the pixel.  The pixel layout view for the left line prop shows the wrong location for the pixel  number one so it's just not going to play correctly for the prop created with the starting location on the right.  You can compare this to the arch prop which also has left and right starting options.  You'll see that the pixel numbering is different for those starting on the right as compared to the line-connected prop starting on the right.

Edited December 23, 2022 by Brad Stucky
error in observation and additional content

[Jimehc]

you showed us how the strings are mounted (controller in center)

But how are the strings defined -

are those suppose to act as a continuous line -

Edited December 23, 2022 by Jimehc

[Brad Stucky]

2 hours ago, Jimehc said:

you showed us how the strings are mounted (controller in center)

But how are the strings defined -

are those suppose to act as a continuous line -

Thanks for your help and patience, Jimehc.  They are supposed to be 2 pairs of separate lines for pixels across our roof top and across our gutters.  None of them line up with each other since we have 2 sections of roof at different levels.   The feed for all 4 lines is from the center where the 2 roofs meet.   Now that the show is not running, I can do some actual testing.  I will work on the problem this morning and get it straightened out.  I recreated these 4 lines as custom props and will simply create a new show preview and assign it to my sequences if need be.  To check this out, I did pick a sequence that has channel level programming for these props and they were matched up properly when I assigned the new preview to this sequence so it should work for the other sequences as well.  The custom props were created with the pixel layout as I need it and I have several other custom props that I know work correctly so I'm confident that will work out.  I did notice that the blue dot evidently does not mean starting location for pixel one, even in custom props.  It seems to just be a reference point so that you know that you've flipped the prop in the preview.  That's probably the part that is still messing with me, particularly since some of the built-in props are generated with that blue dot at pixel one location,  but I've got the day to figure this out.  I will add here if I discover anything else.  Thanks again.

Edited December 23, 2022 by Brad Stucky

[Brad Stucky]

5 hours ago, Brad Stucky said:

Thanks for your help and patience, Jimehc.  They are supposed to be 2 pairs of separate lines for pixels across our roof top and across our gutters.  None of them line up with each other since we have 2 sections of roof at different levels.   The feed for all 4 lines is from the center where the 2 roofs meet.   Now that the show is not running, I can do some actual testing.  I will work on the problem this morning and get it straightened out.  I recreated these 4 lines as custom props and will simply create a new show preview and assign it to my sequences if need be.  To check this out, I did pick a sequence that has channel level programming for these props and they were matched up properly when I assigned the new preview to this sequence so it should work for the other sequences as well.  The custom props were created with the pixel layout as I need it and I have several other custom props that I know work correctly so I'm confident that will work out.  I did notice that the blue dot evidently does not mean starting location for pixel one, even in custom props.  It seems to just be a reference point so that you know that you've flipped the prop in the preview.  That's probably the part that is still messing with me, particularly since some of the built-in props are generated with that blue dot at pixel one location,  but I've got the day to figure this out.  I will add here if I discover anything else.  Thanks again.

I grabbed a spare pixel controller and hooked up 2 150-pixel ribbons to do some testing in the house.  It appears that the motion effects channel mapping doesn't match channel level mapping on either the Connected-Lines, Un-connected-Lines, or Arches when building a prop that has a starting location from the right.  If you double-click on the first channel of a right-fed prop that has channel level programming enabled, the prop definition screen opens showing channel one like you would expect, but when you play a channel level event in the the sequence, it starts at the high channel and plays backwards.  This appears to be the case for the preview and actual playback. The only work-around I see is to copy and flip-paste any channel-level events on any of these props that are fed from the right.

 The sequence I created to test this uses a preview of a pair of arches,pair of unconnected lines, and a pair of connected lines, each pair with a right and left starting location.  I moved the channel assignment from each pair of props to another in order to do an actual test on the pixel ribbons.  I applied a motion effect of BARS to each side with the direction opposite for each side and playback of the motion effect seemed to be correct. (left movement to left and right movement to right)  When I applied a chase to the channel level effects, one side (left side) seemed correct but the right side was not.  If you flip the prop in the preview editor, the action then becomes reversed for both motion effects event and channel level events, still leaving them unmatched in playback or channel assignment.  Am I missing something here?

[Brad Stucky]

I just tested version 6.1.8. to see if this might have an effect on what I was noticing and no it hasn't. (None of these props were in a group.) Assuming that anyone that might have had some issues similar to mine and has fixed their playback with these props in some fashion, I certainly wouldn't expect any software change that might affect those efforts while we're in the middle of the playing season.  Although I have several sequences that were channel-level programmed for my affected props, there was really only one that I considered a noticeable playback issue and that was addressed by flipping the channel level programming in that sequence. For myself, I consider the jump into version 6 as soon as it came out, a major success, as was version 5 when it came out.  The new control panel this year is just fabulous! It has such a polished look to it and so many nice additions to function.  Congratulations to everyone involved on that major update.  

Merry Christmas everyone.