Closed marrobHD closed 1 year ago
I like this idea, but it will require a bit of reworking the effect code to support multiple processes. Right now it only supports spinning up one background task, and this would need to allow for a potentially unlimited number. I'm not sure how that would work performance-wise on a raspberrypi.
Would this actually need to be treated as a separate 'process' as such - could the same process just not be chunked into logical groupings - so for e.g, each 'group' would just be a higher level grouping of LED offsets and each group would have a 'next tick' logic which outputs it's next set of LED statuses based on the effect chosen for that group. Then for each cycle, each group output would be added to a buffer and the buffer would be written to the LED strip?
@drewzh that is an option, but I think I would prefer to keep each group as it’s own process. That way only one effect is running per process. It would just be simpler to manage the different effects that way.
Your proposal would also mean that if group 1 were 1,000 pixels long, group 2’s performance may suffer. That’s not likely to be a problem with the currently available effects, but could become an issue down the road as more (heavier) effects are added.
Personally I'd settle for having one set of LEDs always white while a portion of the full set is used for print progress. For example, I have 16 LEDs in my setup. 8 are on the top bar, 6 are on the X axis, and 2 are on the print head. I'd prefer the top bar lights be used for print progress, and the other 8 just be static white. In my case, the top bar lights are the first 8 in the series of 16.
LED groups. I mean, for example if one has leds under the printer, above the printer and next to the printer and can divide them into the above-mentioned areas. The man then turns the LEDs under the printer and white next to the printer when the printer is printing and the above e.g. show the status of the printer (that's how it is now)