Color Order Override does not work with DDP

[dosipod]

What happened?

We have highlighted this issue during the last fix for Color Order Override bug here
#4326 but that was ignored .

Color Order Override works with DDP in MM so it is there for the taken

To Reproduce Bug

Setup DDP and use Color Order Override with both MM and AC , below pic is from MM . It does not work in AC

Expected Behavior

Color Order Override to work with DDP

Install Method

Self-Compiled

What version of WLED?

WLED 0.16.0-dev (build 2412040)

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

NA

Anything else?

Fixed in MM by @troyhacks along with other improvements to artnet output .

It would be ideal that anything done in the future for local leds to consider DDP
as that would be the expected behavior since it is an output

Code of Conduct

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

[blazoncek]

IMO virtual LEDs should not have color order override and should always be considered RGB(W). Why? Because there is no hardware attached to ESP which is the one that can have different color order.

The color order makes sense only on physical LEDs, and if you configure receiving device (the one with LEDs attached) correctly no additional configuration is necesary on the sending device.

This is even more important if you replace a receiving device with different color order than original one. If color order was defined on the sender, you would need to make adjustments there.
And all external SW would need to take that into account, i.e. xLights.
Also local effects would play incorrect colors on such device.

All that said, yes technically it is possible to have COO even for virtual LEDs but it has been left out intentionally for the reasons stated above.

[dosipod]

@blazoncek Although you may have noticed we post a lot on DDP , the real aim for us with DDP is mainly for beta testing as we can not keep re-flashing or testing on other permanent units having physical leds so DDP not behaving the same as physical leds output would simply make testing harder or prevent it so I hope you get the idea . Seeing that in MM was the reason we highlight it again

[netmindz]

You mention that is doesn't work in AC. but I don't see it in AC as an option and I agree with @blazoncek that it only makes sense for output

Sender should send RGB then if receiver has a mix of different LEDs you map to the correct order

[dosipod]

@netmindz Yes the option is only in MM and I did not argue with @blazoncek about if that make sense and I do not even own any leds other the ws2812 to test such issues.

The only idea we have is to just be able to do beta testing and encourage others to do so without flashing on fixtures that is having leds , this idea is just that in some cases we seen flashing hard to reach fixtures with Alpha and Beta may lead to issues and hence it would just simplify the task of testing . On the other hand I would like to know who added that to MM and why do so if that is not useful in other cases so at least making that an option might be a good idea but the whole thing is not a critical so it is fine .

[netmindz]

I don't understand why the absence of this feature makes testing harder @dosipod

Surely it's easier the way it currently is. You set the color order on the device that has the physical LEDs attached, then that never needs to change. If you were doing it on the sender side then you would have to remember which target devices need what every time you try and different sender

[dosipod]

@netmindz The receiving devices we have are not touched ,some with old builds ,custom builds ,( even some still with the color order bug we know about ) and we do not wish to change their firmware or setting hence we use DDP but it is not really only that at this point as seeing that in MM must mean there are use cases for it .From our side we prefer to have everything that is using DDP behaves exactly the same as real output which is not limited to color order but as said it is not critical

[dosipod]

@netmindz I hope you are not targeting my posts , please do not close any of them , you can ask me to close them as by doing so you are saying that the way it is done in MM is the wrong way

[netmindz]

No offence meant. I clearly misinterpreted your comment about not being critical.

MM isn't wrong, it's just not a feature that is advisable to have in AC as it's only for unusual setups and would cause more confusion for general issues

[dosipod]

Thank you , I have kept some issues open as we are working to see if we can fix them from our side if no one else has the time to do so , I am having hard time testing other guys work and also doing PRs from our side so I hope you understand