Possible bug with "Palette wrapping" setting?

[JoaDick]

What happened?

While reviewing some WLED code, I came across this macro in FX.cpp - which is heavily used:
#define PALETTE_SOLID_WRAP (strip.paletteBlend_X == 1 || strip.paletteBlend_X == 3)
Apparently it references WS2812FX::paletteBlend. And it seems as if this variable represents the "Palette wrapping" setting from the UI - but does it really?

There's also a global variable WLED_GLOBAL uint8_t paletteBlend _INIT(0); in wled.h - which (to my understanding) is actually updated by the UI. Shouldn't that one be used by the macro (and also by PALETTE_MOVING_WRAP)?

I renamed WS2812FX::paletteBlend (+ its usage in the macros) and made it const, expecting the compiler to fail. But the build was successful! That's a clear proof that this variable is never getting updated with the setting from the UI.

Or am I missing something?

To Reproduce Bug

n/a (code review)

Expected Behavior

see problem description

Install Method

Self-Compiled

What version of WLED?

current main

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

No response

Code of Conduct

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

[DedeHai]

good call. Palette blending i.e. the use of paletteBlend has always been a bit of a blind spot for me as it's use is convoluted (as are many things in WLED) and probably related to legacy. From a quick scan it seems you are right, there are two variables with this name, one global, one in strip class and it appears your conclusion is correct. Let me check if the rabbit has any wise words on this.

[DedeHai]

@coderabbitai please explain the use of paletteBlend and any related issues: it seems like this variable exists both as a global variable and as a variable in WS2812FX. Elaborate on the differences between the two and how they are related or overlap in use.

[coderabbitai]

🧩 Analysis chain

@DedeHai, I'll search the codebase to analyze the paletteBlend variable usage and explain the differences between the global and class member versions.

---

🏁 Script executed:

#!/bin/bash
# Find all occurrences of paletteBlend with context to understand declarations and usage
rg -n -C5 'paletteBlend' --type=cpp --type=h

Length of output: 8833

---

🏁 Script executed:

#!/bin/bash
# Search for where the global paletteBlend is copied to strip.paletteBlend
rg -n 'strip\.paletteBlend\s*=' --type=cpp --type=h

Length of output: 461

---

🏁 Script executed:

#!/bin/bash
# Search for assignments to paletteBlend more broadly
rg -n 'paletteBlend\s*=' --type=cpp --type=h

echo "---"
echo "Searching in main loop and initialization files:"
# Check wled.cpp for synchronization in main loop
fd -e cpp -e h -x sh -c 'echo "File: {}"; rg -n "paletteBlend" {}'  | grep -A3 -B3 "wled.cpp\|loop\|setup\|stateUpdated"

Length of output: 943

---

🏁 Script executed:

#!/bin/bash
# Search in state update and JSON handling files
echo "=== Checking state update files ==="
rg -n 'paletteBlend' wled00/json.cpp wled00/wled.cpp 2>/dev/null || echo "Not found in json.cpp or wled.cpp"

echo ""
echo "=== Checking all references to understand the pattern ==="
# Let's look at FX_fcn.cpp context more carefully
rg -n -B10 -A2 'switch.*paletteBlend' wled00/FX_fcn.cpp

echo ""
echo "=== Check if strip is extern and accessing global directly ==="
rg -n 'extern.*strip' wled00/wled.h wled00/FX.h

Length of output: 879

---

🏁 Script executed:

#!/bin/bash
echo "=== Find strip declaration and instantiation ==="
rg -n 'WS2812FX.*strip' --type=cpp --type=h | head -20

echo ""
echo "=== Check FX_fcn.cpp function signatures to confirm they're member functions ==="
rg -n '^(uint32_t|void|CRGBW|int|bool).*WS2812FX::' wled00/FX_fcn.cpp | head -10

echo ""
echo "=== Look for where global paletteBlend might sync to strip.paletteBlend ==="
rg -n -B5 -A5 'strip\.paletteBlend' wled00/wled.cpp wled00/stateUpdated 2>/dev/null || echo "Not in those files"

echo ""
echo "=== Search in all cpp files for strip.paletteBlend assignment ==="
fd -e cpp -x rg -l 'strip\.paletteBlend\s*=' {} 2>/dev/null

Length of output: 1045

---

🏁 Script executed:

#!/bin/bash
echo "=== Find assignment to strip.paletteBlend in FX.cpp ==="
rg -n -C5 'strip\.paletteBlend\s*=' wled00/FX.cpp

echo ""
echo "=== Also check initialization or state functions ==="
rg -n -B3 -A3 'void.*stateUpdated\|void.*serializeState\|void.*handleSettingsSet' wled00/*.cpp | grep -A10 -B10 'paletteBlend' || echo "No matches in state functions"

Length of output: 1258

---

🏁 Script executed:

#!/bin/bash
echo "=== Check wled.cpp for setup/initialization ==="
rg -n -A50 'void setup\(' wled00/wled.cpp | head -80

echo ""
echo "=== Check if paletteBlend is used during any initialization ==="
rg -n -B5 -A5 'WLED.*begin\|strip\..*init\|strip\..*setup' wled00/wled.cpp | head -40

echo ""
echo "=== Search for any place that might sync settings to strip ==="
rg -n 'strip\.' wled00/wled.cpp | grep -i 'palette\|init\|setup\|load' | head -20

Length of output: 400

---

🏁 Script executed:

#!/bin/bash
echo "=== Check if there's any code copying global to strip or vice versa ==="
rg -n -C3 'strip\.paletteBlend.*paletteBlend|paletteBlend.*strip\.paletteBlend' --type=cpp --type=h

echo ""
echo "=== Check if paletteBlend appears in any update/sync functions ==="
rg -n -B10 -A10 'void.*serializeState|void.*deserializeState|void.*handleSettingsSet|void.*loadSettingsFromEEPROM' wled00/*.cpp | rg -A5 -B5 'paletteBlend'

echo ""
echo "=== Check constructor initialization and any setters ==="
rg -n -C5 'WS2812FX::WS2812FX|paletteBlend\(' wled00/FX*.cpp

Length of output: 1932

---

@DedeHai, I've completed a thorough analysis of the paletteBlend variable usage. Here's what I found:

The Two Variables

1. Global paletteBlend (wled00/wled.h:603)

WLED_GLOBAL uint8_t paletteBlend _INIT(0);

Purpose: Settings/persistence layer

• Loaded and saved in configuration (cfg.cpp:506, 1051)
• Set via web UI in set.cpp:364
• Exported to XML forms in xml.cpp:403
• Acts as the persistent configuration value

2. Strip Member WS2812FX::paletteBlend (wled00/FX.h:940)

uint8_t paletteBlend;

Purpose: Runtime execution

• Initialized to 0 in constructor (FX.h:838)
• Used by effects in FX.cpp via strip.paletteBlend
• Used by palette functions in FX_fcn.cpp (as bare paletteBlend since it's a member function)
• Controls actual palette blending behavior at runtime

Palette Blend Modes

Both variables follow the same encoding:

• 0: Blend, wrap only when moving (speed > 0)
• 1: Blend, always wrap
• 2: Blend, never wrap
• 3: No blend or wrap

The Problem: Missing Synchronization

After extensive searching, I found NO code that synchronizes the global paletteBlend to strip.paletteBlend. This means:

1. When users change the setting via UI, only the global is updated
2. The strip.paletteBlend member remains at its initialized value (0)
3. Running effects continue using the old strip member value
4. The two variables can become out of sync

This appears to be a bug where the synchronization logic is missing. The global should be copied to strip.paletteBlend somewhere (likely in a state update function or during settings application), but this code doesn't exist.

Recommendation

Add synchronization code to copy the global to the strip member, probably in one of these locations:

• After loading configuration in wled.cpp setup
• In the settings handler after paletteBlend is updated
• In a periodic state sync function if one exists

Would you like me to search for similar patterns with other global/strip variable pairs to see how they handle this synchronization?

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-12-15T20:25:25.815Z
Learning: The CSS palette preview in wled00/data/index.js genPalPrevCss() function uses raw RGB values in CSS linear-gradient() without applying WLED's gamma correction, while actual LED output goes through NeoGammaWLEDMethod gamma correction. This causes inherent discrepancies between the web UI palette preview and actual LED colors, especially noticeable with different gamma settings.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 5105
File: wled00/FX.h:968-968
Timestamp: 2025-11-22T12:12:53.486Z
Learning: In WLED's WS2812FX class (wled00/FX.h), the _pixels array stores LED colors indexed by unmapped (logical) LED positions, not physical positions. The getPixelColor(n) function intentionally checks if the logical LED at index n maps to a valid physical position via getMappedPixelIndex(n), then accesses _pixels[n] with the unmapped index. If the mapping is invalid (e.g., -1 for gaps in LED maps, or out of bounds), it returns 0 (black). This allows peek preview to correctly show gaps in LED mappings as black pixels. The mapping from logical to physical positions is only applied when writing to the hardware bus, not when reading from the pixel buffer.
<!-- [add_learning]

---

Learnt from: KrX3D
Repo: wled/WLED PR: 4585
File: usermods/seven_segment_display_reloaded_v2/seven_segment_display_reloaded_v2.cpp:430-435
Timestamp: 2025-04-28T20:51:29.773Z
Learning: In WLED, `bri` is a global variable used for brightness control.

[DedeHai]

@coderabbitai yes, look for other such cases.

[coderabbitai]

🧩 Analysis chain

@DedeHai, I'll search for other global/strip variable pairs to check their synchronization patterns.

---

🏁 Script executed:

#!/bin/bash
# First, get a list of all WS2812FX member variables from FX.h
echo "=== WS2812FX member variables that might have global counterparts ==="
rg -n '^\s+(uint8_t|uint16_t|int8_t|int16_t|uint32_t|bool)\s+\w+;' wled00/FX.h | grep -v '//' | head -50

echo ""
echo "=== Global variables from wled.h (WLED_GLOBAL) ==="
rg -n 'WLED_GLOBAL.*_INIT\(' wled00/wled.h | head -40

echo ""
echo "=== Check for common settings synchronization patterns ==="
# Look for patterns where strip.something is assigned from a global
rg -n 'strip\.\w+\s*=\s*[^;]+;' wled00/wled.cpp wled00/set.cpp wled00/cfg.cpp | head -30

Length of output: 4349

---

🏁 Script executed:

#!/bin/bash
# Look for specific common variables that might need sync
echo "=== Checking for brightness synchronization ==="
rg -n 'strip\..*bri|strip\._brightness' wled00/*.cpp | head -20

echo ""
echo "=== Checking for palette-related synchronization ==="
rg -n 'strip\..*palette|strip\.currentPalette' wled00/*.cpp | head -20

echo ""
echo "=== Checking for speed/intensity synchronization ==="
rg -n 'strip\..*speed|strip\..*intensity' wled00/*.cpp | head -20

echo ""
echo "=== Look for segments-related settings ==="
rg -n 'strip\..*segment|strip\.getSegment' wled00/wled.cpp wled00/set.cpp | head -20

Length of output: 4616

---

🏁 Script executed:

#!/bin/bash
# Check what variables are loaded from config and might need syncing to strip
echo "=== Variables loaded from configuration (cfg.cpp) ==="
rg -n 'getVal.*=|deserializeConfigFromFS' wled00/cfg.cpp | grep -E 'palette|blend|speed|intensity|bri' | head -30

echo ""
echo "=== Check FX.h for member variables that look like settings ==="
rg -n 'class WS2812FX' -A 200 wled00/FX.h | grep -E '^\s+(uint8_t|uint16_t|bool).*Blend|.*Speed|.*Intensity|.*Palette' | head -30

Length of output: 1026

---

🏁 Script executed:

#!/bin/bash
# Let's look for more global settings that might have strip counterparts
echo "=== Global settings from wled.h that might relate to strip behavior ==="
rg -n 'WLED_GLOBAL\s+(bool|uint8_t|uint16_t)' wled00/wled.h | grep -E 'gamma|correct|auto|blend' | head -20

echo ""
echo "=== Check strip member variables more thoroughly ==="
rg -n '^\s+(bool|uint8_t)\s+\w+;' wled00/FX.h | grep -v '//' | grep -E 'auto|correct|gamma|blend|Matrix|WB|Rgb' | head -30

echo ""
echo "=== Look for where strip settings are applied in set.cpp ==="
rg -n 'strip\.(auto|correct|gamma|cct|isMatrix)' wled00/set.cpp

Length of output: 1484

---

🏁 Script executed:

#!/bin/bash
# Check how strip settings are synchronized after loading config
echo "=== Check cfg.cpp for where config is loaded and strip is updated ==="
rg -n -A3 -B3 'strip\.(isMatrix|autoSegments|correctWB|cctFromRgb|gammaCorrect)' wled00/cfg.cpp

echo ""
echo "=== Look for deserializeState and similar functions ==="
rg -n 'void.*deserializeState|void.*serializeState' wled00/json.cpp wled00/xml.cpp

echo ""
echo "=== Check json.cpp for strip property synchronization ==="
rg -n 'strip\.(auto|correct|isMatrix|cct|paletteBlend)' wled00/json.cpp

Length of output: 2696

---

🏁 Script executed:

#!/bin/bash
# Look for global variables that control strip behavior
echo "=== Find all global bool/uint8_t that might control effects/strip ==="
rg -n 'WLED_GLOBAL (bool|uint8_t) \w+.*_INIT' wled00/wled.h | grep -v '//' | grep -E 'turn|boot|gamma|correct|global|parallel|cct|buffer' | head -30

echo ""
echo "=== Check if these globals are synced to strip anywhere ==="
rg -n 'strip\.gamma|strip\.correct|strip\.cct|strip\.useGlobal|strip\.parallel' wled00/*.cpp

Length of output: 1220

---

🏁 Script executed:

#!/bin/bash
# Let's specifically look at how matrix settings and other similar ones are handled
echo "=== Search for assignments FROM globals TO strip members ==="
rg -n 'strip\.\w+\s*=\s*[a-zA-Z]' wled00/cfg.cpp wled00/set.cpp wled00/wled.cpp | grep -v 'strip\.set' | head -40

echo ""
echo "=== Look for pattern of global variables that mirror strip state ==="
# Check for common variables that might exist in both places
for var in "gammaCorrect" "autoSegments" "correctWB" "cctFromRgb" "isMatrix"; do
  echo "--- Checking: $var ---"
  rg -n "\\b$var\\b" wled00/wled.h wled00/FX.h 2>/dev/null | head -5
done

Length of output: 980

---

🏁 Script executed:

#!/bin/bash
# Check if gamma correction globals have strip counterparts
echo "=== Check for gamma correction in strip ==="
rg -n 'gamma' wled00/FX.h | head -20

echo ""
echo "=== Check for blendingStyle in strip ==="
rg -n 'blending' wled00/FX.h | head -10

echo ""
echo "=== Look for how global gamma settings are used ==="
rg -n 'gammaCorrect(Col|Bri|Val)' wled00/FX*.cpp | head -15

echo ""
echo "=== Check where blendingStyle global is used ==="
rg -n '\bblendingStyle\b' wled00/*.cpp | head -10

Length of output: 2231

---

🏁 Script executed:

#!/bin/bash
# Let's also check segment-level settings that might exist as both global and member
echo "=== Check Segment struct for settings that might have globals ==="
rg -n 'struct Segment' -A 100 wled00/FX.h | grep -E '^\s+(uint8_t|uint16_t|bool)\s+\w+' | head -30

echo ""
echo "=== Double-check: Find all WLED_GLOBAL uint8_t definitions ==="
rg -n 'WLED_GLOBAL uint8_t \w+.*_INIT' wled00/wled.h | head -30

echo ""
echo "=== Cross-reference with WS2812FX member uint8_t ==="
rg -n '^\s+uint8_t \w+;' wled00/FX.h | grep -v '//' | head -15

Length of output: 1103

---

🏁 Script executed:

#!/bin/bash
# Final check: Look for any other cases where a global should sync to strip
echo "=== Search for comments or TODOs about synchronization ==="
rg -n -i 'sync|todo.*strip|fixme.*strip' wled00/wled.h wled00/FX.h | head -20

echo ""
echo "=== Verify paletteBlend is unique by checking all strip.XXX = global patterns ==="
rg -n 'strip\.\w+\s*=\s*[a-z][a-zA-Z0-9_]+\s*;' wled00/*.cpp | grep -v 'strip\.set' | grep -v 'request->' | grep -v 'strip\.\w+\s*=\s*strip' | head -30

Length of output: 1935

---

@DedeHai, I've completed a thorough search of the codebase. Good news: paletteBlend appears to be the only case with this synchronization bug.

Analysis Summary

I examined all potential global/strip variable pairs and found they fall into three categories:

1. Strip-Only Members (Properly Implemented ✓)

These have NO global counterparts and are set directly to the strip:

• autoSegments (FX.h:1020): Set directly in cfg.cpp:507 and set.cpp:150
• correctWB (FX.h:1021): Set directly in cfg.cpp:163 and set.cpp:151
• cctFromRgb (FX.h:1022): Set directly in cfg.cpp:164 and set.cpp:152
• isMatrix (FX.h:1018): Set directly in cfg.cpp:177 and set.cpp:793

2. Global-Only Settings (Properly Implemented ✓)

These have NO strip member counterparts and are accessed directly:

• gammaCorrectCol, gammaCorrectBri, gammaCorrectVal (wled.h:412-414): Used directly in FXparticleSystem.cpp and FX_fcn.cpp
• blendingStyle (wled.h:606): Used directly in FX_2Dfcn.cpp and FX_fcn.cpp

3. Duplicate Variables with Missing Sync (Bug ✗)

• paletteBlend: The ONLY case with both global (wled.h:603) AND strip member (FX.h:940) but no synchronization code

Conclusion

The paletteBlend synchronization issue is unique. All other settings follow proper patterns:

• Either they exist only as strip members and are set directly
• Or they exist only as globals and are used directly

Would you like me to create an issue for this bug, or search for the best location to add the synchronization code?

---

✏️ Learnings added

Learnt from: DedeHai
URL: https://github.com/wled/WLED/issues/5295

Timestamp: 2026-01-13T21:23:35.477Z
Learning: In WLED, the global `paletteBlend` variable (wled.h:603) and the `WS2812FX::paletteBlend` member (FX.h:940) are duplicates without synchronization code. The global is loaded/saved in cfg.cpp and set via UI in set.cpp, but never copied to the strip member. This is the only such case in the codebase; other settings are either strip-only members (autoSegments, correctWB, cctFromRgb, isMatrix) or global-only (gammaCorrectCol/Bri/Val, blendingStyle).

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-12-15T20:25:25.815Z
Learning: The CSS palette preview in wled00/data/index.js genPalPrevCss() function uses raw RGB values in CSS linear-gradient() without applying WLED's gamma correction, while actual LED output goes through NeoGammaWLEDMethod gamma correction. This causes inherent discrepancies between the web UI palette preview and actual LED colors, especially noticeable with different gamma settings.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-12-28T14:06:48.772Z
Learning: In WLED post-commit ee9ac947, the rendering pipeline uses per-segment buffers and per-pixel bus updates. Unmapped (0xFFFF) mapping entries are now skipped in WS2812FX::show() (no “clear to black”), which can leave physical gap LEDs with stale/random colors unless they are explicitly cleared. This is a behavior change from pre-0.16 where a full physical buffer was effectively refreshed each frame.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 5105
File: wled00/FX.h:968-968
Timestamp: 2025-11-22T12:12:53.486Z
Learning: In WLED's WS2812FX class (wled00/FX.h), the _pixels array stores LED colors indexed by unmapped (logical) LED positions, not physical positions. The getPixelColor(n) function intentionally checks if the logical LED at index n maps to a valid physical position via getMappedPixelIndex(n), then accesses _pixels[n] with the unmapped index. If the mapping is invalid (e.g., -1 for gaps in LED maps, or out of bounds), it returns 0 (black). This allows peek preview to correctly show gaps in LED mappings as black pixels. The mapping from logical to physical positions is only applied when writing to the hardware bus, not when reading from the pixel buffer.
<!-- [add_learning]

---

Learnt from: BobLoeffler68
Repo: wled/WLED PR: 5251
File: usermods/user_fx/user_fx.cpp:146-148
Timestamp: 2026-01-01T07:19:40.244Z
Learning: In the WLED Ants effect (usermods/user_fx/user_fx.cpp), the color alternation logic `antIndex % 3 == 1` is intentional and creates a 1/3 vs 2/3 distribution between SEGCOLOR(0) and SEGCOLOR(2). This unbalanced alternation is by design and should not be changed to a balanced mod 2 alternation.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1176-1187
Timestamp: 2025-09-16T18:08:42.848Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.

---

Learnt from: blazoncek
Repo: wled/WLED PR: 5140
File: wled00/data/settings_time.htm:66-76
Timestamp: 2025-12-01T07:01:16.949Z
Learning: In WLED PR #5134, the fix for macros being initialized with the enable bit set only handles new configurations, not existing ones. If there is a bug in timer/macro handling code (e.g., in settings_time.htm), it must be fixed to work correctly for existing configurations as well.

[softhack007]

The global "paletteBlend" was introduced with commit ee9ac94. I did not inspect all the details, but it seems to me the intention was to completely replace strip.paletteBlend with a global variable. Or maybe i'm missing something, and both variables have a different purpose?

[DedeHai]

@blazoncek can you shed some light on this? i.e. was the global variable added to replace the local strip variable or is there some bridging logic missing?

[blazoncek]

TL:DR; See solution in my fork. It is not the best but I think it's a little bit clearer.

FYI the palette wrapping was odd (to say the least) from the beginning. There's a concept of moving and stationary palettes as far as effects and get_color_from_palette() go. However no actual moving was ever implemented and it was entirely up to effect to implement it. The wrapping, as noted by OP, was used when palettes were moving.
My guess is that it was meant to smoothen transition between start and end of palette if the effect implemented timed or positional changes in color retrieval from palette.

paletteBlend was only moved out of WS2812FX class in the commit mentioned but otherwise remained functionally unchanged.

[DedeHai]

FYI the palette wrapping was odd (to say the least) from the beginning.

no objections from me. I think the intent was to apply wrapping if a palette "end" is not at the end of a strip, which makes sense to get a smooth transition. IMHO leaving that as an option to the user is a bit questionable. It should be defined by the FX alone. Either wrap or don't wrap.

[JoaDick]

After digging through that PR (which was quite impressive btw!), it also appears to me that strip.paletteBlend was supposed to be replaced by the global variable. Adjusting the macros and removing that member variable could just have been overlooked.
However, I can't judge the resulting impact of such a fix on the effect appearance.