Coloring over an image color

[DanR]

I am using ccr grid that has an image of a piano keyboard. The keys are colored red and green. To simulate a keypress, I created a scene for each key on the piano (of a darker red/green). These scense then overlay the images piano key.

On the actual display, the keys look pretty good, the colors are shown as programmed. But, on the grid output in SS, the piano key presses do not show up at all. It seems as if a color (any intensity) overlays an image containing that color, the display is not modified.

Are there rules when coloring over an image?

[robandwend]

I'll be interested in this too - as this is almost exactly what I was hoping to do (time willing).

[Ken Benedict]

Are you looking for piano key sequences?

[DanR]

I'm still trying to perfect the look when a key is pressed.

That keypress event doesn't display in SS at all, but with the real grid it displays. I was trying to find out why the difference between SS and a real grid.

Dan

[BrianBruderer]

DanR wrote:

I am using ccr grid that has an image of a piano keyboard. The keys are colored red and green. To simulate a keypress, I created a scene for each key on the piano (of a darker red/green). These scense then overlay the images piano key.

On the actual display, the keys look pretty good, the colors are shown as programmed. But, on the grid output in SS, the piano key presses do not show up at all. It seems as if a color (any intensity) overlays an image containing that color, the display is not modified.

Are there rules when coloring over an image?

The SuperStar software allows you to overlay effects. If two different effects try to control the same channel, you have a 'channel collision' There are several ways this could be resolved, but currently what the software does is throw out the shortest command, or if they are the same length, the first one stays and the second one gets rejected.
To do an animated piano keyboard, you can have an image for a raised key and a pressed key and you should use one image or the other, not both at the same time.

[DanR]

Brian, I tried out what you said about a shorter command. I have two pictures below. The first one is in SS and second one from the visualizer (I am not by the grid tonight to perform a real test).

I created one image that contains two squares - a red one and a gray one. I then added three short scenes that contain colored rectangles that overlay the image squares.

I was looking for the shorter commands to be ignored so in this case I would expect the scenes to not affect the image. But this is not what I am seeing.

The image below is the output in SuperStar. Notice how the overlaid colors act different based on the color of the image squares.

Attached files

[DanR]

The image below is the output in the visualizer. Notice how this output is different than the output in SS.

Attached files

[BrianBruderer]

You are doing a good job of testing this. You would have to send me the .sup file for me to figure out exactly what is happening, but I can say this is what the software does.
1) The .sup file just contains the properties of the effects, start and and times, start and end positions, start and end colors.
2) When you 'play' a sequence, a series of channel commands are built based on what is in the .sup file. These channel commands are the same ones that would get exported if you were to do an export. So, the resolving of channel collisions happens at this point in the process. Also, when I say the "shortest" command gets thrown out, I mean the shortest time duration.
3) When does a channel collision occur? Each red, green, and blue element of a pixel is a channel. So if you create a red scene that overlaps with a green scene, the overlap will be yellow, but realize that is not a channel collision because the red and green of each pixel are different channels. However, if you create two green scenes, or scenes with green in them and they overlap, the green channels of the overlap are going to have two conflicting commands. Right now, the software resolves that conflict by looking at the time duration of the two commands and throwing out the shortest one.
4) So I don't know why the SuperStar screen would look different than the Visualizer screen, because the channel collisions have been thrown out in both cases.

Please zip up your .sup file and email it to brian@superstarlights.com and I want to figure out what is going on.