[Feature Request] Proposal: Configurable Strip Segments, Parametric Effects and more

[IARI]

Disclaimer

This proposal suggests some extensive changes which probably have already been suggested in one way or another and are certainly not on the plan in this fashion right now. However I hope, that this proposal still offers value to the process, and maybe could be a source of inspiration for the long term development.
So in advance I want to make clear that

• this proposal should still just be considered a draft that would need to be fleshed out.
• I do realize, that the planning and implementation of the whole proposal would require some major refactoring and a decent amount of time.
• consecutively Introducing subsets of suggested features could be a viable solution.

Maybe after reading it you're thinking "Who the fuck even is this guy and when does he even think anyone has the time for this, all of this is complete overkill" - and of course that's completely fine, throw it in the bin.
However I hope this offers at least some thought-food ;)
Anyways, as a software engineer I could offer support by evolving this idea into something that you see fit to be implemented in some more or less distant future.

Is your feature request related to a problem? Please describe.
My problem is similar to what is described in #57 - however my setup is slightly different.
Before I get into the details, let me explain my setup:

I have installed a WS2812b strip within the enclosure I built for my printer, which is cut into 8 parts.
The parts are mounted on the along the side- and top edges of the enclosure cube.
They I wired them together like this:

• The input signal starts at the bottom, running along the the vertical edges to the top in parallel (1 -> 2)
• Then the input signal continues going around the top/ceiling of the enclosure serially (2 -> 3 -> 4 -> 5 -> 6)
  (The strip in the top-back (5->6) isn't really visible in the image, just the schematic - doesn't matter for my proposal)

The intention was, that:

• the 4 vertical columns could display info like the progress during a pring, or nozzle/bed heating
• the top could display some aesthetic light pattern - or simply proved constant illumination for a cam feed

It should be possible to control both segments independently from each other.

Proposal

Describe the solution you'd like
I propose

• a highly dynamic system that is agnostic to the wiring/setup and offers the option to independently configure segments of led's and their behavior
• an additional layer of abstraction that allows to configure effects on a more general level
• user defined presets, that keep the UX simple and fast.

I would strive to separate the concept of effects from the conditions and their input values as follows:

Terminology:

• segment - a (connected) subset of indices that correspond to a subset of the LEDs on the controlled strip.
  The user would be able to configure a list of segments, where each of them in the most basic form would consist of

  • start-index : int
  • end-index : int
  • name : string
    The ranges of the segments should be disjunct, so the data representation could of course also be just one index per segment.
    The challenge here is to figure out a good UI, that allows the user
  • to change the boundary between 2 segments in a single operation.
  • possibly visualize the ranges on a line with names and colors

• condition - represents a state that is entered by any of the events supported.
  Conditions could be:

  • true (i.e. always)
  • startup,
  • idle,
  • disconnect,
  • print-success,
  • enable-failed,
  • enable-paused,
  • printing
    For more details on how the conditions would trigger, see effect configuration

• effect-inputs:

  • printing-progress,
  • tool-heating-progress,
  • bed-heating-progress,
  • bed-cooling-progress,
  • tool-cooling-progress
  • time (start at 0 and continuously progress towards 1 over time).
    Particularly time could be configurable to allow something like the time of day ([Feature Request] Time of day brightness #27).
    Other crazy things like x/y/z-axis movement could be possible option here.
    The Inputs could be configurable with some input-specific values, like tool index, threshholds etc.
    Additionally, every input value could be configured with general options:
  • factor: float - a factor that would be multiplied with the value - that could act as a speed factor for the time-input.
  • easing: Easing - aside from the normal linear x->x option, a choice of classical easing functions could be applied here - but also square (for a 'blink' effect), or triangle (for a jojo effect)

• (parametric) effect can (for starters) take a single effect-input value that can assume values between 0 and 1, which can
  modulate the behavior over an input value.

  • gradient:

    • from : color
    • to : color
    • hue: boolean
      At any given time, all led's of the entire segment have the same color - make the color fade from from to the to color over the input value.
      if hue is false, just fade by linearly interpolating the RGB values
      otherwise, interpolate HLS values of the colors.
      this would cover: Rainbow, Pulse, Blink, Solid Color

  • walking gradient:

    • from : color
    • to : color
    • width: float
    • hue: boolean
      Like the regular gradient - but instead of over the input, make the color fade across the segment led's. The input-value then modulates the offset for the start-led. Optionally, with the width: float factor, the width of the gradient across the segment can be multiplied, so while the default width=1 would spread the gradient once, width=0.5 would have the gradient spread 2 times, and width=2 would spread only half of the gradient visible across the segment, where the other parts of it become visible over time, as the starting point is modulated.
      this would cover: Rainboy cycle

  • dynamic gradient

    • from : color
    • to : color
    • hue: boolean
    • easing: Easing
      Display the gradient behaves like the current progress bar - "Single pixel" mode can be toggled.

    this would cover: Color Wipe, Color Wipe 2, Bounce, Bounce solo, everything that the current progress effects (including [Feature Request] Single LED for printing progress #70 'single pixel' mode) do and more.
    Aside from the above effects, which are quite generic and can achieve a variety of cool things, of course, there could be other more specialized effects like

  • 'crossover'

  • 'bouncing balls' (tbh, I don'T quite understand what that one actually does, or

  • 'random'.

• effect configuration
  effect configurations put all the aforementioned concepts together.
  The user would be able to configure a list of these configurations.
  A single effect configuration consists of:

  • a segment
  • a condition
  • an effect-input
  • a (parametric) effect

  Given the aforementioned concepts, I hope that a basic intuition for the semantics has emerged.
  Given a particular effect configuration, whenever the plugin decides to execute it's effect on it's segment, I call that effect configuration active.
  A remaining questions is, how exactly the plugin decides which effect configurations should be active at what times, in a way that deals with possible conflicts in a sensible way.
  (WIP, TODO: add suggestion)

Why should this be implemented?
I believe that there are many benefits and possible use-cases for a generic approach like this.
This could

• solve my problem
• solve other problems that have been adressed specifically like [Feature Request] Enhancement to progress effect for printers with LED strip on Z (sides) and X (top) of printer #57, [Feature Request] Linear-gradient effect #59, [Feature Request] Single LED for printing progress #70
• could solve other problems like [Feature Request] Multiple Strip type #60, [Feature Request] Time of day brightness #27, [Feature Request] option to limit certain effects to specific parts of the led strip #116 (which mostly ask for segments in one way or another)
• solve similar problems, for any other possible way one could have configured their strip/s in their printer
• and open up a lot more possibilities

I like the idea of experimenting with my setup - maybe i want to change the led-wiring tomorrow.
Maybe introduce another strip?

[cp2004]

This is kind of one large proposal that covers a lot of comments I have had recently, and a few issues (segments: #116, custom triggers: kind of #120 #102). It's detailed - appreciate the thought that has gone in here!

We'll start with the easy bit: yes to something like this. I have had on my mind recently that I want to implement two big features in this plugin - segment control and custom effect triggers. There is currently zero guarantee of how or when either of those may happen, my hope is not too long but I have a ton of things on my 'ToDo' list that I think would be cool.

Custom triggers

Several different types of trigger here - OctoPrint events, Gcode commands, Host @ commands. For each one, there's the right configuration for an 'effect'. Each type has handlers in the plugin, I sort of thought out this implementation already.

Segment control

Something similar to how WLED does it, this manages segment control reasonably well. I haven't poked at how it does it but given it's on a completely different platform it may not be of much use. The idea here would that be for every event/trigger, any number of segments are assigned to it. Slightly different from what you were getting at, main difference is simplicity - I didn't think there is much need to separate triggers from the effects, so instead of 3 'configuration' sections you have just 2.

The approach I was thinking of taking with all of this was time - it was going to sit in my head for a while, and work through some problems before actually committing to anything. The second thing, is simplicity. The vast majority of users have just one LED strip, that should make some cool patterns above their printer. There's little need for them for such a complex configuration. Predefined effects must stay, I want an out of the box experience - I hate things that I have to configure for a while first to get it to work well.

That's the start, I might add some more comments later.

[cp2004]

Ok, that didn't take long - more comments:

• I would rather implement the core myself, since I'm creating/maintaining it, it has to be something my style that I understand
• I would go for a phased approach, this is not a massive project and doing this all at one would take way too long. Big goal would be to evolve it towards this slowly.

[IARI]

Yep, I suppose that getting into the project at the level, including the communication required would be a huge overhead.
Just let me know, if there is anything you could use help with in a way that you feel would actually save you time.