Consolidate Redundant Effects (and Enhance Other Effects) with "Color Count"

[zowper]

Is your feature request related to a problem? Please describe.

This proposal refines the idea from Issue #4975. For most effects, there is no way to control the number of colors used, which limits both user creativity and the efficiency of the effects list. With a few changes, effects can become much more generalized and powerful.

This feature addresses two key problems:

1. Redundant Effects: The effects list is cluttered with duplicates that only differ by the number of colors they use. This proposal would allow for the consolidation of effects like Chase 2/Chase 3, and Fade/Tri Fade into single, more versatile effects.

2. Limited Control: Many existing effects could be significantly more powerful if users could assign 1, 2, or 3 colors. Effects like Blink, Breathe, Candle, Dissolve, Lightning, Meteor, Puddles, Strobe, Sweep, Wipe, and many others would gain a new level of customization.

Describe the solution you'd like

I propose the introduction of a 'Color Count' parameter for effects, located in the UI below the existing “Speed” and “Intensity” sliders. If the effect supports it, this would allow users to dynamically specify how many colors an effect should use from the current palette.

To ensure a smooth implementation within the current system, this feature would initially be limited to a maximum of 3 colors (and only effects that support it). A single 'Color Count' option is the most elegant and user-friendly solution.

Describe alternatives you've considered

Currently, the only reliable solution is to create a new, redundant effect for each color variation (e.g., Chase 3). This approach is unsustainable and unnecessarily bloats the effects list.

There is also a less reliable solution in the colors tab (e.g. "Colors 1&2") that would be replaced with this more intuitive solution. The existing implementation tends to be confusing for users, displays unused colors, and doesn't work for most effects.

Additional context

Example Use Case:

• Goal: Create a festive, multi-colored meteor shower.
• Colors: A user selects three holiday colors (e.g., Red, White, and Green).
• Effect: 'Meteor'
• Result: The user sets 'Color Count' to 3. The effect now knows the the user wants to use three selected colors and can implement that into the effect code. WLED can now create a dynamic, holiday-themed meteor shower without needing a separate “Meteor 3” effect.

This feature request is a formalization of the excellent discussion and ideas presented in Issue #4975. The consensus in that thread points toward a 'Color Count' or similar mechanism as the ideal path forward.

Implementing this would give users more granular and predictable control over effects, eliminate redundant effects from the UI, and provide a simple and powerful option for customization.

[DedeHai]

#4573

[blazoncek]

What's wrong with using palette with an effect? You can have as many as 16 individual colors.

How those colors are selected depends on how effect is written.

You are welcome to provide a patch that will modify existing effects that you consider worthy of modifications.

[zowper]

@blazoncek That's a great question! From my experience, custom palettes are great for controlling "zones" of color, but not great for rotating through colors (both features are desirable, but they're also distinct features).

To illustrate, the first preset that I mentioned is blink. If there was a preset called "Blink 3", I would expect it to blink "Color 1", then "Color 2", then "Color 3".

I set up a "Custom Palette" to Red, White, Blue (using 6 markers to prevent gradients). Using that, it blinks the front of my house red, the side of my house white, and the back of my house blue.

That is a nice effect for "Blink" with a custom palette, but it's not what I would expect for an effect called "Blink 3".

If we want to generalize and consolidate existing presets (like "Chase 2/Chase 3" and "Fade/Fade Tri"), we would also need to be able to change the "Color Count" rather than using a custom palette.

[blazoncek]

@zowper that's just a question how a particular effect is written. If you are not satisfied with current behaviour, please provide a patch for consideration.

EDIT: Most effects come from the time when the only two options were speed and intensity.

[zowper]

@blazoncek I understand what you're saying, but I'm not dissatisfied with the current behavior. :)

In other words, the effects aren't broken. The "Color Palette" creates expected behavior for "Blink". It cannot, however, replicate an effect called "Blink 3".

What I'm describing is a logical addition that can only be achieved by allowing the user to alter the "Color Count". That way, you can blink a "gradient" ("Blink" with custom palette) or you can blink three colors (theoretical "Blink 3" effect).

[zowper]

The same logic can be applied to all of the effects.

Do you want red puddles on the left of your strip, white puddles in the middle, and blue puddles on the right? Use a custom palette.

Do you want red, white, and blue puddles across your strip? Use color count.

[blazoncek]

And I am saying you can adapt current effects by utilizing new sliders and options, that were unavailable when effects were originally written.
Unless someone needs such behaviour, nobody will adapt it. someone being the one providing a patch.

[zowper]

@blazoncek Oh, perfect! I didn't realize that is what you were saying. I'll dig into the new sliders and options to see if there's something that applies. Thanks for sticking with me and pointing me in the right direction!

[zowper]

@blazoncek After a bit of digging, I found https://kno.wled.ge/interfaces/json-api/#effect-metadata and https://kno.wled.ge/interfaces/json-api/#contents-of-the-segment-object which supports what you're saying about custom sliders and checkboxes.

For my first attempt, I'll try to change "Blink" to be able to select up to three colors. It looks like my best option is to use c3 with the label "Color Count". If c3 is 0-10 use one color, 11-20 use two colors, and 21-31 use three colors.

As a side note, I don't think that there is currently a way to change the number of color options that appear in the "Colors Tab" using parameters, is that correct? In other words, "Blink" will always show 3 colors (but some of them might be unused).

Before I get to work, am I understanding your suggestion correctly? Again, thanks so much for your help! You're fantastic! :)

[willmmiles]

I suggest rather that you add a "swap space and time" tickbox that applies the palette based on time instead of pixel coordinate.

[zowper]

@willmmiles That's a really creative idea for Blink! If you're okay with it, I would still like to implement the idea of "Color Count" because it seems more intuitive and is more generalizable across effects (similar to how "Speed" is generalizable across animations).

For context, I'm doing Blink first because it's an easy and useful upgrade. Afterward, I want to work on an animation called Chase Pattern which will hopefully replace Chase 2 and Chase 3 (with a single and more generalized effect).

With the addition of a custom slider called "Spacing", a one color (or custom palette) Chase Pattern also has meaning. With a single color it simply marches across the strip. With a custom palette, it can begin as red, transition to white, and end on blue as it traverses "zones" on the strip.

To be clear, the expected behavior with Chase Pattern after changing the "Color Count" parameter is that the number of colors changes (very intuitive). The "Color Count" is currently the only difference between Chase 2 and Chase 3.

The end goal is to have a generalized effect called Chase Pattern with the sliders "Speed", "Width", "Spacing", "Color Count".

I would also like to use that knowledge to replace other effects with more generalized solutions. For example, Solid Pattern Tri can become a more generalized Solid Pattern (also with "Width", "Spacing", and "Color Count" parameters).

Blink seems like an easier place to start though! ;)

[willmmiles]

I would still like to implement the idea of "Color Count" because it seems more intuitive and is more generalizable across effects

OK - but be aware I anticipate two issues that are likely to prevent merging that approach:

• (a) Explicit FX Color count is capped at 3. We already have a system if you want more than 3 colors as input to an FX algorithm: it's called palettes. We do not want to have two competing systems in the FX core for configuring a larger set of colors. So if you have any intention to support more than 3 colors, you will need to use palettes for the color input.
• (b) Unused color patches appearing in the UI is a dealbreaker for me. You may find that this is already a bug with some existing FX; that's not an excuse to repeat a mistake.

I appreciate that the current UI makes using a palette for this purpose somewhat more complicated than it needs to be. Patches to improve that would be welcome.

The "Color Count" is currently the only difference between Chase 2 and Chase 3.

Take it as a baseline assumption that #4573 will be merged, ie. "Chase 2" and "Chase 3" are already implemented as one FX. (What's still missing on that PR is the backwards compatibility layer for existing FX IDs -- the design plans to handle that well are an ongoing discussion.) If you want to build out further, I suggest starting with the code from that branch instead of main.

[blazoncek]

"swap space and time"

I like this idea very much!