AR Gravcenter, Gravcentric and Gravfreq effects not reacting to "Rate of fall" Parameter

[recliq]

What happened?

The “Rate of fall” slider doesn’t seem to affect the rate of fall on Gravcenter, Gravcentric and Garvfreq but works on Gravimeter.
It seems to be this way since WLED 14.4 according to my tests so far.
I confirmed it is working as expected on WLED-MM (just tested with 14.7.1).

To Reproduce Bug

Install any version with of WLED > v14.4 with audioreactive enabled and a I2S mic and use Gravcenter, Gravcentric and Gravfreq effects.
The first slider (Rate of fall) doesn't have any effect.

Choose Gravimeter effect and use the Rate of fall slider to see what should happen.

Expected Behavior

The Rate of fall slider should influence the speed of the peak to fall to zero.

Install Method

Binary from WLED.me

What version of WLED?

WLED 14.4 to WLED 16.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

See also https://wled.discourse.group/t/strange-behaviour-of-some-effects-in-wled-16-0/15276

Code of Conduct

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

[softhack007]

@recliq thanks for reporting :-) I think this problem goes back to PR #4145, where all "grav" effects got merged into a single effect function.

On first glance, it appears that gravity is correctly assigned based on the "speed" slider, but then handling of it could be slightly different from the previous effects code => need to check the diffs in detail.

WLED-MM still has the original effects code (with a few improvements like "sound pressure" support), so in MM the behaviour is still as expected.

[softhack007]

@coderabbitai please compare the current WLED implementation of mode_gravcenter_base against the source code of the original 4 functions in WLED-MM.

Look for regression and missed behaviour with respect to the "speed" slider and code that handles the rise/fall of the "Top LED" in each mode. Are there significant differences that would explain the behaviour observed by the user?

[softhack007]

wow, the AI is busy since 18min already 😲 seems like a complicated question.

[coderabbitai]

Coding Plan

Summary

• Root cause identified: the peak-update condition tempsamp >= topLED ignores the offset subtracted when setting topLED, causing modes with offset = 1 to get stuck at topLED = -1 where the comparison is always true
• Fix applies offset to the comparison (topLED + offset) so the gravity fall branch triggers correctly
• Single-line change preserves Gravimeter's working behavior while fixing Gravcenter, Gravcentric, and Gravfreq
• No structural changes required; the existing gravity counter and fall rate formula work correctly once the trigger condition is fixed

Implementation Steps

Fix the Gravity Fall Trigger Condition

The bug occurs at the peak-update comparison on line 6840. The current condition tempsamp >= gravcen->topLED does not account for the offset applied when setting topLED. For modes with offset = 1, when audio drops to zero (tempsamp = 0), topLED gets set to -1. Subsequently, the condition 0 >= -1 is always true, so the else if gravity-fall branch never executes, and the "Rate of fall" slider has no effect.

Update Peak Comparison to Account for Offset

Modify the peak-tracking condition in mode_gravcenter_base to compare the effective new peak value against the current topLED, ensuring gravity fall triggers correctly when audio drops.

• In wled00/FX.cpp at line 6840, change the condition from if (tempsamp >= gravcen->topLED) to if (tempsamp >= gravcen->topLED + offset)
• This ensures that for modes with offset = 1, the comparison correctly determines when a new peak has occurred versus when gravity fall should take over
• Gravimeter (mode 2) with offset = 0 will have unchanged behavior since topLED + 0 equals topLED
• The gravity fall branch will now execute when tempsamp drops below topLED + offset, allowing gravityCounter to control the rate of descent as intended

🤖 Prompt for AI agents

This phase fixes a single-line bug in the gravity fall trigger condition in
`wled00/FX.cpp` inside the `mode_gravcenter_base(unsigned mode)` function.

- Locate the peak-update condition at line 6840 in `wled00/FX.cpp`
- Change the condition from `if (tempsamp >= gravcen->topLED)` to `if (tempsamp
>= gravcen->topLED + offset)`
- This ensures modes with `offset = 1` (Gravcenter, Gravcentric, Gravfreq)
correctly evaluate when a new peak has occurred vs. when the gravity fall branch
should take over
- Gravimeter (mode 2, `offset = 0`) is unaffected since `topLED + 0` equals
`topLED`
- No other changes are needed; the existing `gravityCounter` and fall rate
formula work correctly once this trigger condition is fixed

Research

The four gravity-based audio effects (Gravcenter, Gravcentric, Gravimeter, Gravfreq) share a unified implementation in wled00/FX.cpp via mode_gravcenter_base(unsigned mode). The function uses a Gravity struct containing topLED (current peak position) and gravityCounter (frame counter for controlling fall rate). The gravity fall rate is computed as uint8_t gravity = 8 - SEGMENT.speed/32, which maps the "Rate of fall" slider (0-255) to a period of 1-8 frames between each pixel descent. The key difference between modes is the offset variable: Gravimeter uses offset = 0 while the other three use offset = 1, which shifts the peak dot position relative to the bar.

---

🚀 Next Steps

🤖 All AI agent prompts combined

This phase fixes a single-line bug in the gravity fall trigger condition in
`wled00/FX.cpp` inside the `mode_gravcenter_base(unsigned mode)` function.

- Locate the peak-update condition at line 6840 in `wled00/FX.cpp`
- Change the condition from `if (tempsamp >= gravcen->topLED)` to `if (tempsamp
>= gravcen->topLED + offset)`
- This ensures modes with `offset = 1` (Gravcenter, Gravcentric, Gravfreq)
correctly evaluate when a new peak has occurred vs. when the gravity fall branch
should take over
- Gravimeter (mode 2, `offset = 0`) is unaffected since `topLED + 0` equals
`topLED`
- No other changes are needed; the existing `gravityCounter` and fall rate
formula work correctly once this trigger condition is fixed

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[softhack007]

@DedeHai do you agree with the bunny's assessment?

[recliq]

@softhack007
Seeing it took the AI 16minutes makes me feel a bit less dumb... I had a glance at the code but couldn't spot the bug...

Seems to work.

[softhack007]

@softhack007 Seeing it took the AI 16minutes makes me feel a bit less dumb... I had a glance at the code but couldn't spot the bug...

Seems to work.

@recliq you tried the suggested fix? Feel free to submit a PR if all 4 modes work for you with the fix 😃 Saves me a bit of time on my keyboard 😉 and for putting together a fixture for tests.

[DedeHai]

@DedeHai do you agree with the bunny's assessment?

phew, you are asking for something I did like 1.5 years ago, I have no idea :)

[recliq]

@softhack007
Yes, I applied the fix and it seems fine, will try to place a PR... been a while since i did that ;)