Wrong output on COLOR_ORDER_RGB

[cwshep]

First off, thank you for this project! It has been incredibly useful for a project I'm working on.

I just updated to the latest commit (from a version in September).

I was a bit dismayed I had to pass a pixel ordering on every call to ledscape_pixel_set_color(). Is there a good reason to add this flexibility? Shouldn't any code that calls it just pass the colors in the predetermined order? And if it is necessary, then why not just make it a macro #define, does it really need to be set at runtime? And even if it is set at runtime, why not just pass it once on init?

That being said, perhaps it is something I changed, but for some reason my color order for COLOR_ORDER_RGB is GRB (IIRC), while setting COLOR_ORDER_GBR worked just fine. What is very odd is that I don't see any issues with the case statement that sets the color order in ledscape.c. Can you confirm that you do not have this issue?

[RGB-123]

We have been primarily using/developing opc-server as an interface to the LEDscape code. Alot of the settings you are wanting to change can be handled by configuring opc server. You can see some of these settings by issuing # ./opc-server -h

[Yona-Appletree]

@cwshep Sorry for my late reply here, but it may still be of interest to you. I added that for flexibility, and because it used to be hard-coded for ws2812 LEDs. It's not passed on init or hard-coded because I wanted it configurable, and eventually, configurable for every output channel (though we don't have that yet).

As Ryan said, this version of LEDscape is basically designed specifically for opc-server and direct access to the ledscape API is discouraged, since you won't get interpolation or dithering. And no -- I don't recall having any trouble with color ordering, though I may have missed something.