Hypnosis is a memory hog

[davepl]

The Hypnosis effect has a static declaration of two bytes per pixel that go into base RAM. These should be dynamically allocated using PreferPSRAM or similar. The only catch is the [x][y] addressing in the Draw() code gets harder, but I think we need to reclaim the memory.

[davepl]

BTW, if the allocation actually happens after setup() is called, this will already be in PSRAM for Mesmerizer, so no win - but if it's allocated before setup() - like as a global - then it will use base ram.

[robertlipe]

Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number way smaller than a frame buffer.) So it's really all coming from a similar pool sooner or later,. Assuming it's inside a class that's getting newed anyway. The *real* solution here is to not allocate effects that aren't being displayed. Things not in use shouldn't have a cost. But I know there's resistance to that. I'm a bit out of order right now and have a funeral coming up (not mine).but if nobody beats me to it,. I'll take this one.

…

On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> wrote: BTW, if the allocation actually happens after setup() is called, this will already be in PSRAM for Mesmerizer, so no win - but if it's allocated before setup() - like as a global - then it will use base ram. — Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[davepl]

It’s not currently a malloc. It’s static decl.

…

On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote: Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number way smaller than a frame buffer.) So it's really all coming from a similar pool sooner or later,. Assuming it's inside a class that's getting newed anyway. The *real* solution here is to not allocate effects that aren't being displayed. Things not in use shouldn't have a cost. But I know there's resistance to that. I'm a bit out of order right now and have a funeral coming up (not mine).but if nobody beats me to it,. I'll take this one. On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> wrote: > BTW, if the allocation actually happens after setup() is called, this will > already be in PSRAM for Mesmerizer, so no win - but if it's allocated > before setup() - like as a global - then it will use base ram. > > — > Reply to this email directly, view it on GitHub > <#586 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.*** > com> > — Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>. You are receiving this because you authored the thread.

[davepl]

…but it could be contained inside a dynamically allocated object, and therefore be OK. But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK. If you think there are effects that can contract their memory usage, we could just add an End() function that is called like Start(), and effects could manage their memory that way pretty easily. But I haven’t looked very hard yet! - Dave

…

On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote: It’s not currently a malloc. It’s static decl. > On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote: > > > Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number > way smaller than a frame buffer.) So it's really all coming from a similar > pool sooner or later,. Assuming it's inside a class that's getting newed > anyway. > > The *real* solution here is to not allocate effects that aren't being > displayed. Things not in use shouldn't have a cost. But I know there's > resistance to that. > > I'm a bit out of order right now and have a funeral coming up (not > mine).but if nobody beats me to it,. I'll take this one. > > On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> > wrote: > > > BTW, if the allocation actually happens after setup() is called, this will > > already be in PSRAM for Mesmerizer, so no win - but if it's allocated > > before setup() - like as a global - then it will use base ram. > > > > — > > Reply to this email directly, view it on GitHub > > <#586 (comment)>, > > or unsubscribe > > <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE> > > . > > You are receiving this because you are subscribed to this thread.Message > > ID: ***@***.*** > > com> > > > — > Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>. > You are receiving this because you authored the thread. >

[davepl]

OK, I read the code :-). All of these things are constructed as a result of InitEffectsManager and hence they’ve got access to PSRAM. Non-issue, I think!

…

On Jan 8, 2024, at 2:30 PM, Dave Plummer ***@***.***> wrote: …but it could be contained inside a dynamically allocated object, and therefore be OK. But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK. If you think there are effects that can contract their memory usage, we could just add an End() function that is called like Start(), and effects could manage their memory that way pretty easily. But I haven’t looked very hard yet! - Dave > On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote: > > It’s not currently a malloc. It’s static decl. > >> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote: >> >> >> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number >> way smaller than a frame buffer.) So it's really all coming from a similar >> pool sooner or later,. Assuming it's inside a class that's getting newed >> anyway. >> >> The *real* solution here is to not allocate effects that aren't being >> displayed. Things not in use shouldn't have a cost. But I know there's >> resistance to that. >> >> I'm a bit out of order right now and have a funeral coming up (not >> mine).but if nobody beats me to it,. I'll take this one. >> >> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> >> wrote: >> >> > BTW, if the allocation actually happens after setup() is called, this will >> > already be in PSRAM for Mesmerizer, so no win - but if it's allocated >> > before setup() - like as a global - then it will use base ram. >> > >> > — >> > Reply to this email directly, view it on GitHub >> > <#586 (comment)>, >> > or unsubscribe >> > <https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE> >> > . >> > You are receiving this because you are subscribed to this thread.Message >> > ID: ***@***.*** >> > com> >> > >> — >> Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>. >> You are receiving this because you authored the thread. >> >

[robertlipe]

Sounds right. If it's inside the class, it's (sort of) dynamically allocated - as a global ctor, I think. (That's the part I groused about.) It'd be different if it was outside the class and a global, where it would land in .data instead of on the heap. Or the other heap. From memory (I'm AFK) I *thought* I cleaned all that kind of thing up from its arduino-esque heritage when I modernized them, but I couldn't have faked shock if I'd missed one or more. In their original form, all the effects lived in separated executables (Atmega328, you know...) so lifecyle of memory wasn't exactly a concern. I do think we have more than a few matrix effects that allocate large-ish things. I think life, for example, was one as was one of the fires. As a broad measuring stick, grep for '[MAT_WIDTH][MAT_HEIGHT];' or maybe with an explicit multiplication in declarations. If that keeps all/most our allocations out of the arena all the time, jolly good. I don't think I knew about start(), so if there are things we can move from thectors, we should. If ther's someclever reference counting voodoo we can do to not manually manage it, even better. If there's something we can methodically do better, I'd even go back and update "my" branch of effects that didn't make it so that anyone wanting to manually bring those forward can benefit. On Mon, Jan 8, 2024 at 4:34 PM David W Plummer ***@***.***> wrote:

…

OK, I read the code :-). All of these things are constructed as a result of InitEffectsManager and hence they’ve got access to PSRAM. Non-issue, I think! > On Jan 8, 2024, at 2:30 PM, Dave Plummer ***@***.***> wrote: > > …but it could be contained inside a dynamically allocated object, and therefore be OK. But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK. > > If you think there are effects that can contract their memory usage, we could just add an End() function that is called like Start(), and effects could manage their memory that way pretty easily. But I haven’t looked very hard yet! > > - Dave > >> On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote: >> >> It’s not currently a malloc. It’s static decl. >> >>> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote: >>> >>> >>> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a number >>> way smaller than a frame buffer.) So it's really all coming from a similar >>> pool sooner or later,. Assuming it's inside a class that's getting newed >>> anyway. >>> >>> The *real* solution here is to not allocate effects that aren't being >>> displayed. Things not in use shouldn't have a cost. But I know there's >>> resistance to that. >>> >>> I'm a bit out of order right now and have a funeral coming up (not >>> mine).but if nobody beats me to it,. I'll take this one. >>> >>> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> >>> wrote: >>> >>> > BTW, if the allocation actually happens after setup() is called, this will >>> > already be in PSRAM for Mesmerizer, so no win - but if it's allocated >>> > before setup() - like as a global - then it will use base ram. >>> > >>> > — >>> > Reply to this email directly, view it on GitHub >>> > < #586 (comment)>, >>> > or unsubscribe >>> > < https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE> >>> > . >>> > You are receiving this because you are subscribed to this thread.Message >>> > ID: ***@***.*** >>> > com> >>> > >>> — >>> Reply to this email directly, view it on GitHub < #586 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>. >>> You are receiving this because you authored the thread. >>> >> > — Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD324KMGGOTQ7O4MTCKTYNRYAZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHEZDOOJSHA> . You are receiving this because you commented.Message ID: ***@***.***>

[davepl]

Construct() and Destruct() could be called on Start() and End(), could they not? Then it would release most memory when not active. I don’t see any large matrix-sized allocations in base memory… if you can find one, let me know! _ Dave

…

On Jan 8, 2024, at 3:05 PM, Robert Lipe ***@***.***> wrote: Sounds right. If it's inside the class, it's (sort of) dynamically allocated - as a global ctor, I think. (That's the part I groused about.) It'd be different if it was outside the class and a global, where it would land in .data instead of on the heap. Or the other heap. From memory (I'm AFK) I *thought* I cleaned all that kind of thing up from its arduino-esque heritage when I modernized them, but I couldn't have faked shock if I'd missed one or more. In their original form, all the effects lived in separated executables (Atmega328, you know...) so lifecyle of memory wasn't exactly a concern. I do think we have more than a few matrix effects that allocate large-ish things. I think life, for example, was one as was one of the fires. As a broad measuring stick, grep for '[MAT_WIDTH][MAT_HEIGHT];' or maybe with an explicit multiplication in declarations. If that keeps all/most our allocations out of the arena all the time, jolly good. I don't think I knew about start(), so if there are things we can move from thectors, we should. If ther's someclever reference counting voodoo we can do to not manually manage it, even better. If there's something we can methodically do better, I'd even go back and update "my" branch of effects that didn't make it so that anyone wanting to manually bring those forward can benefit. On Mon, Jan 8, 2024 at 4:34 PM David W Plummer ***@***.***> wrote: > OK, I read the code :-). All of these things are constructed as a result > of InitEffectsManager and hence they’ve got access to PSRAM. Non-issue, I > think! > > > On Jan 8, 2024, at 2:30 PM, Dave Plummer ***@***.***> wrote: > > > > …but it could be contained inside a dynamically allocated object, and > therefore be OK. But I’m not fully cromulent on all the construction paths > and their timing. If they’re loaded dynamically by effects manager, and are > NOT instantiated in the table, then it’d be OK. > > > > If you think there are effects that can contract their memory usage, we > could just add an End() function that is called like Start(), and effects > could manage their memory that way pretty easily. But I haven’t looked very > hard yet! > > > > - Dave > > > >> On Jan 8, 2024, at 2:28 PM, Dave Plummer ***@***.***> wrote: > >> > >> It’s not currently a malloc. It’s static decl. > >> > >>> On Jan 8, 2024, at 2:04 PM, Robert Lipe ***@***.***> wrote: > >>> > >>> > >>> Any mallocs over, I thinf, 16 bytes already goes into psram. (It's a > number > >>> way smaller than a frame buffer.) So it's really all coming from a > similar > >>> pool sooner or later,. Assuming it's inside a class that's getting > newed > >>> anyway. > >>> > >>> The *real* solution here is to not allocate effects that aren't being > >>> displayed. Things not in use shouldn't have a cost. But I know there's > >>> resistance to that. > >>> > >>> I'm a bit out of order right now and have a funeral coming up (not > >>> mine).but if nobody beats me to it,. I'll take this one. > >>> > >>> On Mon, Jan 8, 2024, 2:41 PM David W Plummer ***@***.***> > >>> wrote: > >>> > >>> > BTW, if the allocation actually happens after setup() is called, > this will > >>> > already be in PSRAM for Mesmerizer, so no win - but if it's > allocated > >>> > before setup() - like as a global - then it will use base ram. > >>> > > >>> > — > >>> > Reply to this email directly, view it on GitHub > >>> > < > #586 (comment)>, > > >>> > or unsubscribe > >>> > < > https://github.com/notifications/unsubscribe-auth/ACCSD34RZZT6TON2DNYO4HDYNRKWZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRG44DQMJWGE> > > >>> > . > >>> > You are receiving this because you are subscribed to this > thread.Message > >>> > ID: ***@***.*** > >>> > com> > >>> > > >>> — > >>> Reply to this email directly, view it on GitHub < > #586 (comment)>, > or unsubscribe < > https://github.com/notifications/unsubscribe-auth/AA4HCF7DRHFD4QE2GV26SQDYNRUQBAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHA4TIMRWGI>. > > >>> You are receiving this because you authored the thread. > >>> > >> > > > > — > Reply to this email directly, view it on GitHub > <#586 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACCSD324KMGGOTQ7O4MTCKTYNRYAZAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHEZDOOJSHA> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF5IFS5K5TJHLWXTG73YNR3S5AVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHE2TSNZWG4>. You are receiving this because you authored the thread.

[rbergen]

But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK.

Effects are constructed during the execution of setup(), but pretty much towards the end of its invocation. Also, effects are explicitly allocated using psram_allocator.
The table that's put together in effects.cpp only contains the effect factories; this means that in practice the table is a couple of small lambdas for each effect in the list.

Any mallocs over, I think, 16 bytes already goes into psram.

It's actually anything over 128 bytes. But considering the previous that shouldn't matter anyway.

Construct() and Destruct() could be called on Start() and End(), could they not?

The challenge with the destruct part is that we have no "End()". An effect is told to prepare itself for drawing through Start(), and then told to draw frames through Draw(). It is not told when its time in the spotlight has ended.

[robertlipe]

On Tue, Jan 9, 2024, 7:55 AM Rutger van Bergen ***@***.***> wrote: But I’m not fully cromulent on all the construction paths and their timing. If they’re loaded dynamically by effects manager, and are NOT instantiated in the table, then it’d be OK. Effects are constructed during the execution of setup(), but pretty much towards the end of its invocation. Also, effects are explicitly allocated using psram_allocator. The table that's put together in effects.cpp only contains the effect factories; this means that in practice the table is a couple of small lambdas for each effect in the list. Any mallocs over, I think, 16 bytes already goes into psram. It's actually anything over 128 bytes. But considering the previous that shouldn't matter anyway.

That sounds cromulentier. I wonder if psram_allicator is never actually. Called for anything < 128 bytes anyway. Is that a candidate for instrumentation in step 1 and then removal a few days/weeks after that if no warnings fire? Construct() and Destruct() could be called on Start() and End(), could they

not? The challenge with the destruct part is that we have no "End()". An effect is told to prepare itself for drawing through Start(), and then told to draw frames through Draw(). It is *not* told when its time in the spotlight has ended.

IMO, it's ok to not know when everything has ended, but to know when another has started. We could destroy when calling visual mute, but that probably makes visual turbulence when restarting. Would we satisfy Paretto calling End() just before calling Start(), but only if the current effect (current until a few milliseconds. Before that) is set? It matters less that we may never have 0 that are Start()Ed than that we have fewer than 2, Right? We have scores of effects. Especially on Matrix, where we may have large secondary rendering buffers or other per pixel data, this might add up - literally doubly so for the 64*64 cases. Are multiple displays unique (e.g 128*128 canvas) or are they pixel mirrored? That, too, is probably a road little traveled. We don't KNOW, but I don't get the impression we have people running thousands of strip pixels, but we. Should review that directory,. Too. I got into a talk on Dave's most recent video with a guy that said he tried to run 16*300 2812s, but then project supported only HUB75 then,. So he moved on. I don't think we can actually run > 8 strips in any non-trivial configuration on any esp32 because FastLed doesn't support the modern 16 channel. Parallel I/O mode in the new S3. Let's not get into that. (That discussion had...issues.) Addressing the matrix case to have at most one effect armed is likely a win for us. —

…

Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3ZFVD2OOKC6UOESGGTYNVD5BAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGA4DSNBSGU> . You are receiving this because you commented.Message ID: ***@***.***>

[davepl]

Unless I’m just inferring, you keep implying that there are lots of effects with base memory demands, but having looked, I’m dubious. I’ve been careful to allocate things dynamically from PSRAM in all my own effects, and have fixed most others. But like I said, if you KNOW about any, call it out so I can fix it. But call it out or move on, I’d say :-) I have no had luck reducing the PSRAM allocation auto limit below 96, as WiFi has code that needs base memory but doesn’t spec it, so it gets PSRAM and chokes if you go to 64. The practical limit of the number of LEDs you can control is a function of refresh rate, which I explain in the latest video. So haveing 16x300 LEDs would work, but (a) you’d have fewer buffers since they’re larger, and (b) the refresh rate will be terrible. I run a 5000 LED strip on the Cabana, but it’s broken into four of a about 8x144 each The umbrella shows that NDS can handle 8 parallel effects, and the tiki lamp can receive multiple channels over wifi, too. So that all works. - Dave

…

On Jan 9, 2024, at 9:11 AM, Robert Lipe ***@***.***> wrote: We have scores of effects. Especially on Matrix, where we may have large secondary rendering buffers or other per pixel data, this might add up - literally doubly so for the 64*64 cases. Are multiple displays unique (e.g 128*128 canvas) or are they pixel mirrored? That, too, is probably a road little traveled.

[robertlipe]

On Tue, Jan 9, 2024 at 12:10 PM David W Plummer ***@***.***> wrote:

Unless I’m just inferring, you keep implying that there are lots of effects with base memory demands, but having looked, I’m dubious. I’ve been careful to allocate things dynamically from PSRAM in all my own effects, and have fixed most others. But like I said, if you KNOW about any, call it out so I can fix it. But call it out or move on, I’d say :-)

Some. Not lots. Now that I'm able to get to a computer, using the regex I cited earlier, a starting place might include PatternLife.h: bool alive[MATRIX_WIDTH][MATRIX_HEIGHT]; That should become a bitset, as I did for StrobeDiffusion in 0dccb01. Life has a few others. PatternSMHypnosis.h: } rMap[MATRIX_WIDTH][MATRIX_HEIGHT]; PatternSMRadialFire.h: byte XY_angle[MATRIX_WIDTH][MATRIX_HEIGHT]; PatternSMRadialFire.h: byte XY_radius[MATRIX_WIDTH][MATRIX_HEIGHT]; PatternSMRadialWave.h: } rMap[MATRIX_WIDTH][MATRIX_HEIGHT]; PatternSMRainbowTunnel.h: } rMap[MATRIX_WIDTH][MATRIX_HEIGHT]; There is a larger number holding local arrays for many hundreds of trackingOBJECT_MAX_COUNT (100 * 5 floats, two ints, and a bool)) or SNAKE_LENGTH (64 * several arrrays) or [MAX_DIMENSION][MAX_DIMENSION]; (the largest of WIDTH, HEIGHT) and the various noise arrays were in the thousands, IIRC. Changing these from what's ultimately an operator new[] to populate the effects objects to an actual operator new that's called when we come to life. Quit fixating on PSRAM vs. Base heap or even .data. My point is that we have scores of effects objects and at any time, only one of them is actually live. Whether it comes from this pocket or that pocket matters (and we're finally now all agreeing that effects will come from the PSRAM pocket) less than that MOST of it is not in use at any one time. We want to add new effects, but if an effect has a non-trivial cost when not in use, we have a scalability problem.

I have no had luck reducing the PSRAM allocation auto limit below 96, as WiFi has code that needs base memory but doesn’t spec it, so it gets PSRAM and chokes if you go to 64.

My 16 number was from memory. Offhand, I don't dislike 128. Keeping it large enough to keep the Arduino Strings (few of our strings are 128) from fragging that heap is probably a good idea anyway.

The practical limit of the number of LEDs you can control is a function of refresh rate, which I explain in the latest video. So haveing 16x300 LEDs would work, but (a) you’d have fewer buffers since they’re larger, and (b) the refresh rate will be terrible.

I'm quite aware of the signalling rules for both HUB and WS. On the older ESP32's, there are 8 RMT channels, but only 4 really work at once so synchronization between the channels is janky. On newer ESP32s, there are only 4 RMT channels and FastLED (which is still kind of deadlocked, struggling with Arduino and ESP8266) doesn't support either the 16-channel I2S mode or the 24-channel parallel "general gpio" mode while we're using I2s for sound because we only have so many I2S controllers. So I think that even with local effects (lots of bouncingballs or lasers or fireworks or whatever) we'd fall back into bitbang mode on a bunch of those strips and then fall into the collapse of the sun. I see now that NightDriver caps the NUM_CHANNELS to 8 anyway, so this is all rather a distraction. It was just opening the discussion that not all arrays are in the HUB code; some might be in strip. A secondary point was that we don't seem to have a lot of people fussing about limits of running zillions of WS parts. Nobody's whining (enough to do anything about it) that we can't control 24 channels on the hardware that supports that. I think that crowd is just using other software...and probably something closer to a Pi than an ESP32. Eight 2Ghz cores lets you get away with murder. Of all things, this dude was talking about building a clock, so I can't imagine he needed much more than a 1Hz refresh anyway and I have no idea why he needed enough pixels to be a "real" monitor. He used a different project. I'd only been thinking about this after seeing the ESP32 page on a project that's like FastLED: https://github.com/Makuna/NeoPixelBus/wiki/ESP32-NeoMethods ... and thinking about what a support horror that would be.

I run a 5000 LED strip on the Cabana, but it’s broken into four of a about 8x144 each

Are you really using 8 channels or is it like your umbrella where you're just teeing one channel to DIN on multiple strips? (Not that your umbrella isn't freakin' awesome.) Can you run meteor on channel 0, fireworks on channel 2, particles on channel 3, laser on 4, ... ? (Yeah, I get that would be custom and far from something that's in the tree by default.)

The umbrella shows that NDS can handle 8 parallel effects, and the tiki lamp can receive multiple channels over wifi, too. So that all works.

Well, it's one effect, just electrically connected to 8 strips, right? // The "Tiki Fire Umbrella" project, with 8 channels #define LED_PIN0 5 // Only one pin, it's routed to all 8 spokes. Independent turned out not to be that useful. #define NUM_CHANNELS 1 I don't see any "real" projects in the tree that use NUM_CHANNELS to anything but 1. (I'm sure you have projects that aren't in the tree. Me, too.) The "how many strips can we REALLY do" thing is a distraction. I'd much rather use your valuable attention to think about the paper-cut problem of effects taking up memory when they're simply not in use and may not even be even shown. Let's think about that one more and forget the "angels on the WS281x Data Out Pin" thing. RJL

…

- Dave > On Jan 9, 2024, at 9:11 AM, Robert Lipe ***@***.***> wrote: > > We have scores of effects. Especially on Matrix, where we may have large > secondary rendering buffers or other per pixel data, this might add up - > literally doubly so for the 64*64 cases. Are multiple displays unique (e.g > 128*128 canvas) or are they pixel mirrored? That, too, is probably a road > little traveled. — Reply to this email directly, view it on GitHub <#586 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32EELKX77UWJF3GILTYNWBXXAVCNFSM6AAAAABBSBFOYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGU2DMOJXGQ> . You are receiving this because you commented.Message ID: ***@***.***>