Fastled: CPixelView doesn't handle reversed direction and color utility functions

[MFornander]

We just discovered a few bugs in the rainbow and gradient methods inside CPixelView when the view is mapped on a reverse direction led array. We fixed the rainbow but I'm filing this issue to remember to fix all methods and perhaps even add a few perlin noise methods on CPixelView.

Repro steps

1. Fold one physical strip of 100 LEDs in half and connect to driver.
2. Add all 100 LEDs using addLeds.
3. Create two "logical" view of LEDs using CPixelView's ctor, one with (leds, 0,49) straight and the other as (leds, 99,50) reversed direction.
4. Call fill_rainbow twice on both views with the same values.

Expected result:
Both logical strips showing the same rainbow, with identical colors side by side, as if they were two different strips connected in parallel to controller.

Actual result:
Incorrectly mapped rainbow color on the reverse direction view.

I'll file a Merge Request with fixes sometime after the dust settles this year.

[MFornander]

Note to self since we had to recreate the fix again today:

pixelset.h @ 166
OLD AND BUSTED
::fill_rainbow(leds+len+1,-len,initialhue,deltahue);

NEW HOTNESS
::fill_rainbow(leds+len+1,-len,initialhue-deltahue*len,-deltahue);

Still planning to file that MR but want to look at the sibling gradient methods to make sure they are not flawed as well.

[focalintent]

The reverse direction stuff is something I’m not really happy with in general, and I’m likely to gut it sooner rather than later :)

[MFornander]

The reverse direction was absolutely awesome for us. We have two strands folded on a pole, and thus have four CPixelViews as if we had four physical strands. This saved us connectors and development time since other incarnations are not folded. Very cool abstraction. Don't gut it :)

https://www.facebook.com/groups/717748685076630/permalink/769367623248069/

[focalintent]

Sorry - should've been clearer - I'm going to gut the implementation - I've been meaning to look at some different ways of doing range selectors as a general idea, to give something a lot more flexible (forward ranges, backward ranges, repeat patterns, skip lists, etc...)

[kriegsman]

Cleaning up old issues; closing this one, since @focalintent is no longer around to work on it. May reopen it in the future.

[MFornander]

Hey @kriegsman would you like an MR that addresses this in the current codebase?

[kriegsman]

That would be great actually, if you can and feel like it.