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 👎

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

• 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.