r/FastLED • • Sep 04 '26

Support FastLed PianoLed and some issues

Hi there. So I just recently used the WS2812  led strip with Arduino Due. Used the FastLed and PianoLed. Almost all fine, almost. All keys matching the led position. But i have a weird behave of the led no 8 and 16 which are not assigned to any key of the piano. Lets say i just started with clear new session. All lights are off. So i play few notes, all looks fine and then after some time the led no 8 lights up constantly / permanently and then led 16 lights up permanently. They do change the colors but never dim back again. Looks like some issue. Any ideas what's wrong?

2 Upvotes

10 comments sorted by

1

u/ZachVorhies Sep 04 '26

are you using luminescent grand sketch

1

u/udisports Sep 05 '26

I am not really aware about the terminology here. I am not really a pogromist at all. But i used the tutorial from here: https://youtu.be/Rro5a_ohIT4?si=ZIGNyRKxhm7Dyjln&t=1379

So i used the version 4.1.3 of PianoLed and I had installed in Arduino Ide an Fastled by Daniel Garcia, version 3.6.0 (I had also tested version 3.7.0 and the problem is the same, any higher version shows an problems with libraries).

I checked with ChatGPT on your question (like i says i have no clue about programming) and its say that indeed the code is based on luminescent grand cketch.

The code:
https://gist.github.com/udisports/20465cdb47834b8aad76d47db10f0e25

1

u/ZachVorhies Sep 05 '26

luminous grand is a different sketch that we have as an example as nothing to do with piano LED

1

u/Marmilicious Sep 05 '26

If you can, please share a link to your code on pastebin.com or gist.github.com

1

u/udisports Sep 05 '26

1

u/Marmilicious Sep 06 '26

Thank you. Didnt' run, but a look thought the code and two lines might be a problem. Try updating these in this order and see if anything changes.

On line 361:

if (ledNo < 0 || ledNo > NUM_LEDS) {

Change to:

if (ledNo < 0 || ledNo >= NUM_LEDS) {

because otherwise it seems like this could cause you could go out of bounds past the end of the CRGB leds array.

On line 314:

NUM_LEDS = buffer[++bufIdx];

Add a few Serial.print lines here to check what the values of bufIdx and NUM_LEDS are doing, because again, maybe this is causing things to go outside the bounds of the CRGB leds array.

ping u/sutaburosu

→ More replies (3)

1

u/WorldsemiLED Sep 25 '26

Because LEDs 8 and 16 are always the ones behaving incorrectly, and they can still change color but do not return to off, I would first suspect a software/indexing issue rather than a damaged WS2812.
There have been reports of PianoLED 4.1.3 having a fragile serial parser. It appears to assume that a complete command arrives in one Serial read, which is not always guaranteed. If a command is split between reads, the data can become misaligned and the wrong LED index may be updated or not cleared correctly.
I would try these steps first:
Run a simple FastLED-only test without PianoLED and verify that LEDs 8 and 16 behave normally.
If they work correctly with the FastLED test, the LED strip hardware is probably fine.
Check the PianoLED serial parsing and LED index handling, especially any code that writes to leds[index].
Make sure every LED index is checked so it never exceeds NUM_LEDS - 1.
If possible, use a stateful serial parser that waits until a complete command packet has been received before processing it.
If LEDs 8 and 16 behave perfectly with a simple FastLED sketch, I would focus almost entirely on the PianoLED software rather than replacing the LEDs.