Handle multiple universes correctly in FastLED example

[niliha]

Hi, first of all, thanks for the great work!

I noticed, that multiple universes are not handled correctly in the FastLED example.

Imagine having 171 LEDs connected. One universe can hold 170.66 LEDs. In the real world this means that one universe can hold 170 LEDs witch 3 color channels each and the first two channels of the 171th LED (512 mod 3). Therefore the second universe should start with the third channel of the 171th LED.

However, the current code leaves out the two last channels of the first universe making the second universe start with the first channel of the 171th LED.

I couldn't get Resolume to work with the current code. Even when I enabled the "Align output" option, the colors still get shifted at the "universe border" due to the misalignment.

Therefore I made these changes. Basically, instead of looping over the received universes in packages of 3 channels, now every channel is set individually. This avoids any gaps in the display buffer.

Let me know, what you think and I hope this is helpful for others!

[rstephan]

"Right" depends on your point of view. If your Resolume software can't handle the format than it's a missing feature. So you are welcome to contribute.

Unfortunately no one before has mentioned this behavior. Therefore I don't want to change the current example. For more clarification I have added a note for how to handle "my" Pixel-Format. But you can make an extra example with the "No-Gap" format. You can call it ArtnetWifiFastLEDNoGap.

Additionally I have some questions about your code:

• Why are you changing names, data types and other code styles? Please honor the existing code style, event if you don't agree with it, and even if I am not consistent by myself ;-)
• Is the universesReceived-Guard working? I don't think so. You have changes the if from == 0 to basically != 0
• Please remove the debug Serial.println() output.

Thanks

[niliha]

Thanks for you reply!

I agree that these should be two separate use cases and that there is no right and wrong in this sense. Maybe I did configure something wrong in Resolume. I will give it another try.

In the meanwhile, I'm happy to contribute a separate example.

About the code style: I'm sorry, I didn't intend to disrespect you. I adapted your code to my code style when I integrated it into my project and did not make the effort to revert it back, but instead tried to make it roughly look like your example. And you're right about the universesReceived check. It must be if (!universesReceived[i]) instead of if (universesReceived[i]).

Should I stick to your coding style in the separate example too?

Thanks!

[rstephan]

A "diff" is harder to read if all lines are changed because other "layout" things. And it is good practice to "only" fix the problem.

With your own example, there is nothing to compare to, so I will accept the new code style. Just fix the small problems, as mentioned above:

• No Serial.println() in onDmxFrame(), it can be a huge bottleneck in terms of LED frame rate.
• The universesReceived thing.
• And it's #include <...> for all files (less than, grater than). A include with "..." is for local files in the same directory. For this example, there will be only one .ino file, no other file.

If you are ready, close this pull-request and open a new one with just the new example (right folder, right name).

Have fun!

[niliha]

Great, I will do so!