I've heard that there is a library that groups LEDs into single addresses, primarily as a way around the memory problem (UNO can only address so many LEDs on a strip). I can't find this library, does anyone know what I'm talking about?
I'm basically creating several large "pixels" so I need each meter of LED strip to do the same thing, as in meter 1 is all red, meter 2 is all off, meter 3 is all white, etc.
@J-M-L I’m not seeing how that library helps, can you elaborate?
As I understand it, the only way to have one setting or memory location for multiple LEDs would be to change the function that pumps out the serial LED data so it can do tricks like that on the fly.
If that is the case, the WS2812s would be a bit of a challenge, with the timing of the pulses, whilst APA102 LEDs, which use a data line and a clock line, would be very straightforward as one can use these LEDs with no memory representation of the entire strip whatsoever. And take whatever time it does…
by using your own SPI interface to the APA102.
You can still use library features if you need to exploit the library tools ability to translate colors &c., just do it on a dummy strip of as few pixels as you need, then pluck the data out for your own on-the-fly calculations.
I used digitalWrite and hand done data transfer, it got better with fastDigitalWrite and of course build-in SPI can be used and is fastest. I was mostly seeing if I could run the APAs w/o any (any) library whatsoever.
a7
I guess I might have miss-understood the question
I was hoping you hadn’t… it would be a nice if not often used capability.
a7
the approach you exposed is probably the correct way - and possibly what the mysterious library does 
Fasled has the concept of CRGBSet array, see
but that won't help with the memory size
You could connect the data lines of all the LEDs in each large "pixel" together to a single input, although I"m never looked to see how many LED inputs the output from the previous pixel can drive.
is why I should have read the entire post before running off to see about these super pixels. 
a7
it's a digital command so...
Probably quite a few. It’s logic and CMOS, so. But that’s a crap-ton of retiring rewiring.
@prismspecs how ‘bout some numbers? How many real pixels? How many work as one, so how many conceptual super pixels?
You may figure how to save memory, but unless you did as @david_2018 has come up with, you still will need the time it takes to talk to all the real pixels which may present its own upper limit on how many you can handle, esp. if you are trying to maintain a decent frame rate.
a7
Thanks for your replies.
There are 8 windows acting as superpixels, each is composed of 2 meters of LED strips at 60 per meter. So, 120 pixels per "superpixel" x 8 = 960. I am also hoping to double this, if possible! I will start with 8. Now I have a MEGA so it can handle this, and frame rate is not super important (I could easily deal with 5 fps).
OK, so the mega has enough memory, and my back of the envelope sez you’ll make 5 FPS easily.
With only 8 concept pixels, I would probably just instance 8 strips and write some code that makes each strip act more or less like one LED.
It’s straightforward to make an array of strip objects; once you get a function like I hint at below working, you never have to deal with strip objects or that array.
void setConceptPixel(int theStrip, theColor)
{
// for loop set all pixels in strip to the color
for (int thePixel = 0; thePixel < stripLength; thePixel++;
myStrip[whichStrip].setPixelColor(thePixel, theColor);
// or maybe use the flood fill to set them all
// show this strip (or have it shown at the same point as all of them are higher up elsewhere later
myStrip[whichStrip].show();
}
a7
It should be possible to modify the library to generate output for 120 LEDs for each pixel in the pattern buffer, although you need to be very careful to maintain the correct timing - the code at that level is done in assembly language.
Alternatively, instead of a strip of 8x120, wire as two parallel strips of 8x60, with half of each super pixel in each strip, with the advantage of doubling the maximum frame rate. Four strips of 8x30 in parallel would likely work on a atmega328.
Thanks again. For clarity, in this setup do you mean that each concept pixel would be a separate object instance, each connected to a separate digital pin?
edit: followup question, will a 10-20 meter run of wire carrying the ground and digital signal from Arduino be okay?
and why do you consider to use 960 individual addressable Neopixels if you just ned 8 strings a 120 LEDs? Have you ever considered to use 8 "simple" RGB stripes and controll them not like "Neopixel"s but like 8 RGB LEDs?
You can use multiple strips on as many pins as it would take, or the same idea of handling the complexity with a function could mean using just one pin and some maths.
Like concept pixel N would translate to single strip pixels N * conceptGropuSize through (N + 1) * conceptGroupSize…
And with @noiasca ‘s question it is time to ask what you will be actually doing. It may make no difference but if you are using existing code that works, say, with an eight pixel strip and you want 8 super pixels, smart LEDs might make more sense.
But only a little. I just like the neopixels or APA LEDs because less hardware.
As for the long run of the data signal I don’t know. The data rate on neopixels is fairly high, so this is a good question to resolve…
a7
I'm not aware of a library that does what you want, but I often use a Nano to drive more LEDs than can fit into its RAM. I split the LEDs across multiple pins, and render and display them sequentially. FastLED makes it easy to do this, e.g. 641 LEDs on a Nano.
This forum post has good information about WS2812 signal integrity.
pretty cool, I had never read that part of the doc. So you can just reuse the buffer.
Yes, you can use that technique to save memory. Or, to improve frame rates when only a subset of the strips are changed. Or, by also changing FastLED's idea of how long each strip is, to send the minimum LED data to bring the LEDs into sync with the framebuffer.
I'm sure there's other use cases that haven't occurred to me.