Piano Colors

[VBryan]

Not sure what I am doing wrong but I can't seem to change the colors of the keys in the Piano effect.  Anyone know how to do this?

[Santacarl]

I noticed the same thing.....I also ran into a situation where the keys (lights) stay on after they 'play'....and after a few seconds the whole display is on.....until a very soft passage comes and then the lights go out..... I gave up trying to use the effect because I figured I would be the only one who knew it was a piano....

[danj]

I have only played around with that one time and I found the same thing--figured I would be the only one who knew it was supposed to be a piano.....

[djulien]

The way this was intended to work is that when a Shapes file is selected, it is scanned and a list of unique colors is built.  The example Piano-ExampleKeyTopShapes.png contains 4 colors: 2 shades of green for on/off for the white keys, and 2 shades of red for the black keys.

If there are no user-selected color palette entries for the effect, those colors are used as-is.  OTOH, if there are user-selected colors (checkbox on in front of them), they are mapped one-by-one to the list of colors found in the Shapes file.  This means that the effect works best with 4 colors selected in the Piano effect, 2 shades of 2 contrasting colors.

Which settings are you using with the Piano effect?  (or post part of your XML file).  I've only tested some specific combinations of an example usage scenario, so there are probably other combinations of options that don't work as intended. 

don

[VBryan]

Here is my .xml File.  It does not seem to make any difference what colors I choose they do not register in the preview window.  Prior to printing the .xml I changed the pallet to red(1), green(2), yellow(3) and blue(4) all others unchecked.  I have also noticed some missing notes from a file I created so I made a test file with the notes 21 to 108 each given 1 second on the screen and notes 29 thru 35 and 65 thru 71 were missing.  My display is a 50 x 8 matrix (Shows 28 keys) and the missing notes were where the keyboard folded over.

[attachment deleted by admin]

[VBryan]

After some further testing I have discovered that if you change the colors, update the Grid, Save the file then close Xlights when you reopen it the colors are there.  However I discovered that if you Make color 1 (White keys when not depressed) white or color 3 (White keys when depressed white the colors will not display they just show as black.  In addition with color 1 white and any other color for 3 when one of the white keys is played it will change the key to color 3 and never go off.

[djulien]

Okay, I think I finally figured this one out.  The problem was related to caching of the Shapes file.  It only analyzed the colors when the Shapes file was reloaded, so if that file didn't change, it didn't bother looking to see if the palette colors changed also.

Hopefully it's fixed now in xLights 3.3.7.  Prior to that version, the work-around is to load a different Shapes file and then back to the one you want, or to just close and re-open xLights.  (either way defeats the cached Shapes file).  Sorry for the delay.

don

[sean]

one note, the last released version is 3.3.5. The next version we will release is 3.3.6. this should happen this week. 3.3.6 will have Don's fix in it.

sean

[VBryan]

Great.  Thanks for the update look forward to the fix.

[VBryan]

I just downloaded version 3.3.6 and part of the problem is solved. However if you make either of the keys pure white there is a problem.  If you make the key white when struck it just does not show up and if you make the key white when it is not struck the struck color will persist on the screen eventually filling the keyboard with that color.  All the other colors seem to work fine and if you change the value of white by just one digit in the define custom colors it works as well.  Also the problem of the missing notes on my matrix (50x8) where the keyboard folds is still there.

[djulien]

Here is what I think is happening for the missing notes.  When determining the horizontal spacing, the layout calculation wraps on octaves.  That way, if you have enough pixels for, say, 2 octaves but the notes/cues file spans 5 octaves, then the notes for the higher octaves will still be displayed in their correct relative position within the octave (ie, A is always on the left, G is always the right end of the octave, etc, so they are more recognizable).

The default width for keys is 3 pixels, so a matrix that is 50 pixels wide would be enough for 16.7 white keys (~ 2.4 octaves).  Rather than only displaying 2 octaves and then leaving a blank spot on the right where the 3rd octave would start (which would be ~ 30% of the width in this case), it displays and clips partial octaves.  This results in the first 2 octaves being completely visible, and then the first ~ 5 notes of the 3rd octave being visible with the last 7 notes of that 3rd octave being clipped.  That seemed like reasonable behavior when I wrote it, but in this case it throws away the upper 7 notes of every third octave, which is significant.

What would be the best way to change it?  I think the octave wrapping is desirable so equivalent notes don't move around within one octave to another.  The default key width could be changed to 4 in this case (to show 2 octaves with only 2 pixels wasted at the end), or 2 (to show 4 octaves).  I had picked 3 originally because it gave reasonably proportional key shapes.  2 or 4 pixels wide will make the keys look a little disfigured, but I suppose that is preferable over just not displaying ~20% of them.  Yet another possibility would be to transpose any clipped keys to the next octave up - however, this might be confusing to show, say, C4 at the right of the matrix and then D4 in the middle of the left-most octave (after it wrapped).  Are there any other options, or do any of these sound preferable?

For the problem with white, I will take another look at that.  (might be related to transparent background in the Shapes file).

don

[VBryan]

I think that making the key width anything smaller than three will make parts of the keyboard look very strange.  I don't follow you math for a 4 pixel wide key I get 1 Octave with 22 pixels left over at any rate I think 3 pixels is the best number to use.  I understand the concern about maintaining Octaves and given that, I would blank out the last five notes on my matrix and wrap at the end of the last full octave.  That way all of the notes are displayed and it maintains the look of a keyboard. It would look better if the keyboard were centered in the matrix but that is not a big issue.

[djulien]

> It would look better if the keyboard were centered in the matrix but that is not a big issue.

Okay, I can make that change.  That will split up the empty spot so it's at least balanced.

For the white display problem, it turned out to be related to transparent pixel detection.  There is a fix for that in the next release.  In the mean time, the work-around is as you suggested - use a value that is not exactly white (ie, off by one).

don

[VBryan]

I downloaded 3.3.9 and looked at the piano effect it looks like we still have an issue.  The 3rd and 6th octaves are being lost in the wrap on my matrix.

[djulien]

I've made another fix to the version coming after 3.3.9.  Hopefully that one will show the notes missing between octaves.

don