Implement WLED issue #3554 - [dis]respect LEDmaps when receiving UDP

[spblat]

Adapted from from my request wled#3579 in Aircookie/WLED which was resolved by wled#3554:

Is your feature request related to a problem? Please describe.

When a string of LEDs is operating independently, sometimes it’s helpful to use LEDmaps. When that same string is controlled using DDP/UDP, we may or may not not want the active LEDmap to affect the ordering of the LEDs.

Describe the solution you'd like
In main branch issue wled#3554, a client-side setting was implemented which “allows to tell WLED to not respect LED maps for all realtime modes.”

Describe alternatives you've considered
I considered alternatives in my original issue, wled#3579

Thank you!

[softhack007]

Hi @spblat, thanks for the pointer.

Actually the upstream (AC WLED) solution introduces a performance bottleneck in setPixelcolor(), so we'll need to find a different way to implement this feature in WLED-MM.

We'll look into it after the upcoming release.

For the time being, you could use a preset without ledMap and activate it before starting realtime mode.

[softhack007]

PS: I think the "HTTP Request API" can be used to switch to a specific preset ID

&PL= | 1 to 250 | Applies entire preset

https://kno.wled.ge/interfaces/http-api/#presets

[spblat]

PS: I think the "HTTP Request API" can be used to switch to a specific preset ID

If you could use the HTTP or JSON API from one WLED to tell another WLED to change to a specific preset, that would be a perfect workaround. But I don’t think this is possible. The implemented fix in main WLED adds an option on the DDP receiving side to disregard its local ledmap when DDP receiving is active. Isn’t that as workable here as it is there?

[softhack007]

main WLED adds an option on the DDP receiving side to disregard its local ledmap when DDP receiving is active. Isn’t that as workable here as it is there?

No it's not. It is technicially possible to do a similar change, but this change is in conflict with the performance improvements we did in MM.

As I explained before, the change in main WLED (aka upstream) would introduce a new performance bottleneck, while just supporting a very special use case.

That's what I meant when saying

Actually the upstream (AC WLED) solution introduces a performance bottleneck in setPixelColor(), so we'll need to find a different way to implement this feature in WLED-MM.

Edit: I didn't mean to say "its impossible". But we'll need to think about a more efficient implementation to add the same feature in MM - because reducing performance of setPixelColor() is not an option.

[dosipod]

I am also not in favor of doing that from the slave side as that does not solve the issue if we are using old builds for the slaves .
Something we used from the master is create a blank ledmap and once it is activated then DDP worked as expected , seems dirty workaround but it means we could do that from master @softhack007 what do you think ?

[softhack007]

@spblat @dosipod I'm thinking about adding the "disrepect" ledmap kill switch for DDP receive, however with a more efficient implementation in setRealtimePixel(). This would mean that you can auto-disable the ledmap, however only when "main segment only" is not used. The reason is that the "main segment" requires at least an internal ledmap, otherwise "serpentine" and other panel and segment specific options will not work.

Would it be sufficient for your use cases if "disrespect" only works when DDP (or other protocols) control the complete strip, but not when DDP streaming is limited to "main segment only"?

[spblat]

Thank you @softhack007. I think you’re saying that the solution you propose would not allow a subordinate WLED to have segments that are not controlled by DDP while DDP is active. Your solution would satisfy my use case; I don’t need segments during DDP :-)