Aircoookie / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
https://kno.wled.ge
MIT License
14.48k stars 3.1k forks source link

Event triggers in effects on playlist #4043

Open pfurrie opened 1 month ago

pfurrie commented 1 month ago

Is your feature request related to a problem? Please describe. Yes. One of our WLED controllers needs to run a wipe effect, followed by solid white. The intent is to use a wipe as a transition from off to full on and then stay there. This was accomplished by having two presets:

  1. A wipe with the segment set to do a mirror effect.
  2. A solid preset of full white.

A playlist has one entry: the mirror wipe effect. And one of its parameters is an end preset, using the solid white preset.

This works... kind of. The duration of the wipe effect has to be carefully set so it moves to the end preset at the point when the wipe effect has reached one end. This is a crude way of achieving the desired behavior, and tough to adjust. If the wipe speed is altered, then the duration has to be fidgeted with as well to match.

Describe the solution you'd like Have the ability for any effect to raise an event whenever it reaches a node along its path. For the wipe, it would be whenever the wipe completes turning on and another when turning off.

Each playlist entry would have a field for how many iterations of the event would be required (if used) to trigger moving to the next entry in the playlist. This would allow entry steps in the list to be de-coupled from time and be coupled to discreet points in the completion of an animation effect.

Describe alternatives you've considered As described previously, am using the duration of a playlist entry to try to get close to the desired effect.

Additional context No other context to which I can add, thanks.

Thank you for your ideas for making WLED better!

blazoncek commented 1 month ago

You may want to look into #3877

What you are asking is impossible to achieve as each effect has different internal workings and do not have "states" that could trigger "events".

softhack007 commented 1 month ago

Hi,

I think what you are looking for is some kind of "switch on" and "switch off" transitions? This has been requested several times, and there is a PR in work that might provide a solution

I think the "wipe" effect is special because it actually has this "turning point" that could be seen as an event. However it would be very hard to implement your proposal for the general case:

pfurrie commented 1 month ago

I think what you are looking for is some kind of "switch on" and "switch off" transitions? This has been requested several times, and there is a PR in work that might provide a solution

That is something I'm looking for, but a more complete solution would be with some way to raise an event when an effect passes through some node point in the animation.

I think the "wipe" effect is special because it actually has this "turning point" that could be seen as an event. However it would be very hard to implement your proposal for the general case:

I went through all the effects, and all of these have good "turning points" (better thought of as nodes):

There are others that I agree don't have a "turning point," but not all effects have the same properties, so this would just be one more property that would allow better control in a playlist. Doing by time makes very limiting and makes it hard to have clean transitions between effects. If an effect is mid-effect and then we switch to another effect, it is effectively a jump-cut and looks bad. An event can easily guarantee this doesn't happen.

  • most of our effects do not have any "turning point" like wipe. Audioreactive effects are driven by audio, 2D effects are drawing nice stuff, effects like "rain" simply simulate raindrops.

Yes, some effects have audio reactivity, some are designed for 2D, and others are purely random with no periodicity. And still others have a good basis for natural nodes by which a change of effect could be triggered. Then you can alter the speed of such an effect but always make the transition when the effect is at that optimal cut point.

  • it's not clear how to deal with "events" coming from several segments. For example, a user could creates 16 segments (one for each row of a 2D panel) and run wipe effects with different parameter inside each segment.

Then limits would be put on the conditions upon which the events can be used. This is not as bad as you think. But there is a good reason to do this, and lots of playlists can be made easier to make smooth, and that smoothness would remain even when making other adjustments (like speed), since event drive transition points will be time independent (right now they are time dependent).

pfurrie commented 1 month ago

You may want to look into #3877

What you are asking is impossible to achieve as each effect has different internal workings and do not have "states" that could trigger "events".

Is there no way to pass a variable from the effect code to the playlist code? If there isn't, what would prevent it?

As far as different internal workings, that is obvious as each effect has a different... effect. But there are commonalities. All audio-reactive effects must interact similarly with the rest of the WLED code in order to have that audio stream passed to is. All effects that have a speed parameter all interface with the speed slider control the same way. Effects have some way of passing data back to the rest of the program to tell it if it is looking for palette info, audio, speed, other other parameters... in order for those options to be shown to the user in the GUI. Similarly, any effects that would benefit from having a countable event or iteration counter could implement that method and raise that value to the calling routine. Once the playlist gets a predetermined number of iterations of an effect, this can kick off a transition to the next preset in the playlist.

Unsure what would make this impossible.

blazoncek commented 1 month ago

The sources are there and you are welcome to implement it if you find a way. I am not as it would be convoluted and would need to "cross-contaminate" the code which I'm not willing to do.

Unsure what would make this impossible.

Nothing is impossible. It is the time and complexity that make it impractical to implement.