I’ve got some ideas but it would be great to hear from the experts!
I must not be an expert because I’m not sure what you’re referring to at all.
Can you elaborate? Do you mean channels on the output expander?
If your setup can chain all of your LEDs in one long string/strip then you can get away with 1 channel.
Sometimes the limitations of that get in the way of the logistics of a piece. Maybe getting a return data path from the end of one to the start of another would be cumbersome, or too long. Maybe you want to mix LED types. Maybe a single string of LEDs would hit data rate limitations. Output expanders can help out in these cases.
“Channel” as a term seems to be in common use here as in an “8-channel” expansion board, or a 64-channel expansion board and etc.
I was more looking for discussion of the reasons for and strategies around employing channels.
And no you don’t have to be or even admit to being an “expert”.
An example project is @wizard Volumetric Cube. https://twitter.com/im889/status/1324884291843547137
And @Scruffynerf’s post Re “Going Big” -
The former employs eight eight channel expansion boards.> The latter, is up in the air, but presumably it can be run in one channel.
So, in one case you’ve got a bunch of terminal strings each needing their own channel, but what it the advantage in that?
Could one run a volumetric cube of some other volumetric shape and also run, say, a scrolling matrix on another channel? Something like that?
So there you go, a bit more information as to the nature of the inquiry.
First two reasons to use channels per @wizard (thanks!)
And here’s a third and fourth!
Yes, more than one terminal strings of LEDs are one of the major reasons to use multiple channels. Otherwise you have to chain them together as a single long string. Using multiple channels allows you to run each string independently from the other.
All of the pixels on each channel are assigned to a pixel index just like it was one single string. Usually you configure these to use contiguous indexes starting from 0, which is what most patterns assume. You can then layer pixel maps or code on top of that to make it do anything you want, just like you can for a single channel/string.
Channels don’t inherently run different patterns, there’s still only the one pattern that is running. Of course that pattern could implement both a volumetric cube and a scrolling matrix based on the pixel index.
I think that covers most of your questions. Let me know if I missed something!
Yes @wizard, thanks so much! As always, complete, generous, fantastic and wizardly.
I dug this up from an older thread -
The buffered neopixel designation in setup is not available in the V3 front end. That designation makes things run much faster on the V2 at least. Is there a reason for this?
I’m assuming that with computationally intensive code things slow down (?)