Brightness acts slow in DMX Effect Segment Mode

[mxklb]

What happened?

When controlling WLED via DMX in "Effect Segment Mode" brightness changes are too slow. In general when using DMX consoles to send brightness changes, these changes are only applied/allowed within certain intervals. This becomes critical, especially when switching brightness channel slider off quickly (to black out DMX fixtures). This behavior makes brightness in "Effect Segment Mode" only controllable correctly, when using slow slider movements :-1:

To Reproduce Bug

Activate DMX and send brightness changes to single segments using external console sliders.

Expected Behavior

Brightness should change immediately as other DMX channels do as well.

Install Method

Self-Compiled

What version of WLED?

above WLED 0.14.0-b1

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

Problem must occur within setOpacity:

void Segment::setOpacity(uint8_t o) {
  if (opacity == o) return;
  if (fadeTransition) startTransition(strip.getTransition()); // start transition prior to change
  opacity = o;
  stateChanged = true; // send UDP/WS broadcast
}

Maybe stateChanged = true .. TBD

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[blazoncek]

Set the transition to 0 and changes will be instantaneous.

[mxklb]

I think it is already 0, I'll check and come back ..

[maxnuglisch]

Same behaviour over here! Not just the Brightness has this problem. Even the color channels only seem to do around one update per second.

WLED 0.14.0-b2 (build 2306020) ESP32 ART-NET Transition is set to 0 (otherwise you dont notice the stuttering but you cant instantly jump between values)

[blazoncek]

I do not use DMX (or other live protocols) but there are a few optimizations that can be done. @mxklb you contributed in the past consider modifying like this: There is no need to check if change is happening as setXxxx() functions do that.

@maxnuglisch @mxklb please post a video of how the issue looks like.

[blazoncek]

@mxklb @maxnuglisch I pushed dmx-transitionless branch which includes a new option (in settings) to ignore WLED transitions. Please give it a shot and report back.

[mxklb]

@blazoncek thanks ..

I will have a look. But actually I am quite busy for the next 6 weeks and can't tell when I find time to do so ..

[mxklb]

@blazoncek the dmx-transitionless branch does not change the behavior in general. When sending DMX brightness via external DMX console, WLED brightness changes are applied way to slow. High frequent DMX brightness changes are applied with a lot of delay. It looks like incoming DMX signals are faster than WLED brightness change implementation.

WLED implementation is actually unable to handle external DMX signals as expected - without significant delay. This behavior makes WLED external DMX control kind of buggy because it's far away from real time - latency for brighntess changes is to big! This must be something in code, not every DMX channel acts that slow. I experience this especially with brightness changes. @maxnuglisch for color changes I can't recognize this latency issue.

There is no need to check if change is happening as setXxxx() functions do that.

I'll try to change relevant code parts and test it again. But I don't think it is causing this latency issue ..

• Test binary from dmx-transitionless branch WLED_0.14.0-b3_ESP32-dmx-transitionless.zip

[blazoncek]

Please clarify:

• are you talking about segment opacity/brightness or global brightness?
• what protocol of communication do you use?
• what DMX mode do you use?
• what is your intended framerate?
• what is the speed of brighness changes (no./s)?
• what is the level (amount) of brightness change?

[mxklb]

• are you talking about segment opacity/brightness or global brightness?

void Segment::setOpacity(uint8_t o) as written above - global brightness acts kind of slow as well

• what protocol of communication do you use?

E1.31 (@mxklb) and ArtNet (@maxnuglisch) as written above

• what DMX mode do you use?

"Effect Segment Mode" as written above

• what is your intended framerate?

at least 50 frames/sec, 100 would be great

• what is the speed of brighness changes (no./s)?

should be the same as framerate (of cause without any transitions)

• what is the level (amount) of brightness change?

min .. max [0..100%], or anything else, but shall not matter

@blazoncek can you tell or test what is the maximum expected framerate an ESP32 should handle? I think it would be nice to get some kind of reference measure for different property changes (opacity, global brightness, color, ..). At least to be able to tell what framerates are expected to be handled properly. Some E1.31/ArtNet software may be able to configure framerates explicitly - to avoid signals beeing thwarted by slow devices.

[mxklb]

I'll do further tests with other tools like https://sacnview.org if I find time to ..

[blazoncek]

I am sorry if it looked like I am asking the obvious, but sometimes parameters (issues) change during resolution. Thanks for clarification.

If you check "ignore transitions" (a new parameter in Settings) or if you completely disable (uncheck) "Crossfade" and "Palette transitions" then WLED changes its state immediately upon receiving a request. No delay or "smoothness" is applied anywhere in such case.

WLED's most common FPS is 42 but that can be changed in Settings up to 120. I have never needed anything above 42 so cannot comment if it works or not and what is the maximum usable FPS.

If you still see "slowness" or delay, after you disabled Crossfade, when changing brightness then you may be seeing network delays or delays in network packet processing over which WLED has no control.

[blazoncek]

@mxklb Any news?

[mxklb]

actually I don't find time for detailed testing, maybe someone else .. nevertheless i'll test in the next 3-4 weeks, hopefully ..

WLED's most common FPS is 42 but that can be changed in Settings up to 120. I have never needed anything above 42 so cannot comment if it works or not and what is the maximum usable FPS.

Where to find this setting? Or how to change it to be 100 FPS?

[blazoncek]

I know you are quite capable to find and fix the problem. 😄 When you'll be testing or changing code, check led.cpp, handleTransition(). It is the piece where global brightness may be transitioning.

You can change intended FPS in LED Preferences, Advanced section. Be aware, though, that Solid effect disrespects that and only updates at 3-4 FPS.

[peteroliveira123]

I know you are quite capable to find and fix the problem. 😄 When you'll be testing or changing code, check led.cpp, handleTransition(). It is the piece where global brightness may be transitioning.

You can change intended FPS in LED Preferences, Advanced section. Be aware, though, that Solid effect disrespects that and only updates at 3-4 FPS.

Hi, Im new to WLED, and starting a project to creat DMX fixture with ws2812 for live shows. Using the artnet or e131 input works great with my esp9266, except for the solid effect. Im using the effect mode with 15 channels, already tried with both artnet and e131, and with broadcast, unicast and multicast, the results is always the same.

I think my problem is the same as the one of the topic, basically when in solid effect I move the dimmer channel fast but the feedback from the led strip is very laggy and not smoth as expected. As I was reading your reply I figure that the problem should be exalty that. The fact that solid effect disrespects the FPS goal and stays on the 3/4 FPS.

So is there a way to change it on the code? And compile it to see if resolves my problem? So that the solid effect respects the goal FPS? I've been trying to look for it on the code but with no result.

Thanks!

[blazoncek]

Just change the effect to some other. 😃

[peteroliveira123]

I know that, but for a live show I want to be capable of using the effects and also static color, and there is no other effect that allows to have static color.

Even with other modes, RGB or DRGB, the problem is the same. If I could tweak the code so that the solid effect respects the refresh rate than the functionality would be perfect. Do you know which file of the software should it be?

[blazoncek]

Yes there are, actually a few that can do that. Palette effect with speed 0 and palette " Color 1" and I'll let you discover others. 😉

[deggle]

Right - I need to read these threads better - I wrote a long reply on another thread, then moved it here, then I read this bit...

Be aware, though, that Solid effect disrespects that and only updates at 3-4 FPS.

So, that's clearly the root cause of the problems we're all having.

As I see it there are only a few possible solutions to this:

1. Revise 'Solid' so that it ignores this FPS limit when running in DMX mode (or by settings toggle).
2. Create a new 'Solid Fast' (or similar) mode that doesn't reduce the FPS (could be hidden from GUI menu).
3. Accept the workaround of using one of the existing animated FX tweaked to produce a solid colour.

I don't know the code well, but I assume 2 may be a quick an easy solution for someone familiar with the code to implement? However, I appreciate it's more code & more work, so if the workaround (while hacky and I don't like it), is the current accepted solution that's fine.

It would be good to get an official position on this (@blazoncek / @Aircoookie), as it would close this issue and also https://github.com/Aircoookie/WLED/issues/3245.

Thank you!

Ps. If we do have to go with the workaround, I went with the effect 'Percent' set to 100% as I assumed that's one of the FX with lower processor load - does it matter, any thoughts on that? May be worth noting the workaround recommendation (and the reasoning) on the DMX docs page.

[blazoncek]

1) most likely not (but you never know...) 2) why? waste of resources 3) that's the only option AFAI'mC

I pointed out the fastest (lowest complexity) effect.

[deggle]

Thanks for confirming Palette is the lowest complexity, so that's the way to go. On the basis of your reply, I think you can close the two issues down? Thanks for your help.

[mxklb]

The workaround is for changing complete LED strip color more efficient. I'll test it soon ..

Palette effect with speed 0 and palette " Color 1" and I'll let you discover others. 😉

@deggle I don't think this addresses this issue, brightness still acts slow in DMX Effect Segment Mode.

[deggle]

For me this workaround does result in reasonably quick responses on the dimmer (CH1) however it doesn't feel like it's reacting quite as quickly as perhaps the RGB is with this setup. It could be that a minor blip in a dimmer chase is probably more noticeable than an RGB crossfade (I've been testing this by having the desk do chases with crossfades). However, when I tap the blackout button the response is immediate, which is not the case when not using the workaround (i.e. 'Solid' mode). I've been able to create a profile for my desk (Chamsys MagicQ) that defaults the mode to 065 and the palette to 002 so unless intentionally changed these value are always sent to WLED even after a 'clear' (or where no values are set in the programmer).

[github-actions[bot]]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED! ✨