Additional display geometries + a request for review of include/globals.h

[robertlipe]

I went to look at the configuration for Mesmerizer and either it's misdocumented or I really don't understand the config. I know it run HUB75 for 64x32. I don't know how the rest of the configuration also drives a 48x16 grid.

Tweaking Matrix for 64x64 doesn't Just Work. I suspect that the additional E pin isn't being driven but haven't chased it through. What's the config tweak to enable that and how do you enable multiple HUB75 panels?

If you have multiple panels, whether HUB75 or WS, how do you configure the geometry so that it trickles through to the g()->xy() function so you could configure, say, five panels in a plus sign configuration?

0P0
PPP
0P0

so that 0, 0 goes into dead space, 64,0-64+63,0 goes to the top panel, and such?

Actually, that description is almost the XmastTrees build.

Also, is Hexagon under the eaves? Ditto CHIEFTAIN. And Spectrum

Now that I'm reading the whole file, there's clearly just some copy-pasting gone wild. Could someone that's familiar with each of those targets please run through this file and update them to match reality?

Is it legit to configure both USE_MATRIX and USE_STRIP ? I can imagine having two renderers running, but the single config points of WIDTH and MATRIX kind of falls down. So imagine the plus configuration above PLUS a 64x32 and a 64x64 HUB75.

If someone can fluff the descriptions, if it's helpful, I'd volunteer to split that giant #if that runs from #if DEMO through 'no other project' into #include target/FOO blocks to make them a little easier to review (and grep) as the project grows. Maybe we can split globals into target-specific block, the kind of after-target fixups that follow, and then the kind of C++ globals goo that every C/C++ project needs starting around the "Final headers."

Or not, but please help fix paste-os in that file and help me understand the rules about adding additional lighting units or in additional geometries like a ws 32x32 chained after an 8x8.

[rbergen]

You're asking a lot of questions in your post. I've read them all, but I'll only respond to the points I think I can:

• Maybe I'm misreading your first sentence, but the rest of the config for Mesmerizer doesn't also run a 48x16 grid. Other configs can, and for instance Spectrum does, but that doesn't also run a HUB75.
• At the moment it's an either/or thing when it comes to what you drive. You either choose to drive a HUB75 panel by defining USE_MATRIX to 1 - which is now always done in the platformio.ini build config -, or you drive WS2812 strips/grids. This is sorted out towards the top of globals.h: if USE_MATRIX is not defined to 1 by line 125 at the time of writing, USE_LEDSTRIP is defined to 1 instead.
  Depending on which one of the two is defined, LEDMatrixGFX is compiled in and used to take care of the actual drawing to the HUB75 panel, or LEDStripGFX is used instead to drive the WS2812 strip(s)/grid(s). There is one variation to this, which is when HEXAGON is defined to 1.
• HEXAGON is an extension of USE_LEDSTRIP, which comes with its own GFX class HexagonGFX. That is a subclass of LEDStripGFX - which means it also drives a WS2812 device - but implements the different geometry that comes with a hexagon shape.
• Driving both a HUB75 panel and a WS2812 grid may be technically possible, but the codebase currently doesn't cater for it. It's not just the either/or in globals.h; the code takes as a premise that there is one list of effects (managed by EffectManager) that is being displayed on one type of graphics device (LEDMatrixGFX, HexagonGFX or LEDStripGFX).
• I'd say there is currently no inherent support for non-oblong shapes composed of smaller grids. As was done with HEXAGON, one would probably add a new LEDStripGFX subclass to deal with the specifics of whatever shape one would like to use. This could potentially be generalized into a GFX class that can handle different "tetris-like" compositions, but I haven't even begun thinking that one through.
• The contents of platformio.ini have indeed been composed in part by copying and pasting - as globals.h has been as well. I'd say it makes sense, because some project configs in globals.h are enabled for different chips/boards in platformio.ini. That said, a major overhaul of platformio.ini has already been done some time ago, by yours truly. That introduced the separation of device configurations from project configurations ("envs"), the introduction of "feature configs", etc. Smaller updates have been made since, and PR Add PrepareFrame() and PostProcessFrame() to GFXBase and subclasses #370 that is now open includes fixes for some glitches that have been introduced in recent times. I'm not exactly sure what makes you conclude that platformio.ini is out of sync with reality in the broader sense. I do know I can't establish by trying, because I only have the gear for two projects: Mesmerizer on the Mesmerizer board, and Spectrum on the M5StickC Plus. I know both of those work.

[davepl]

Check out the stacking flags for the Matrix. Thats what controls where the next panel appears in logical coords.

…

On Jul 24, 2023, at 2:34 AM, Rutger van Bergen ***@***.***> wrote: You're asking a lot of questions in your post. I've read them all, but I'll only respond to the points I think I can: Maybe I'm misreading your first sentence, but the rest of the config for Mesmerizer doesn't also run a 48x16 grid. Other configs can, and for instance Spectrum does, but that doesn't also run a HUB75. At the moment it's an either/or thing when it comes to what you drive. You either choose to drive a HUB75 panel by defining USE_MATRIX to 1 - which is now always done in the platformio.ini build config -, or you drive WS2812 strips/grids. This is sorted out towards the top of globals.h <https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/2fa544653a9a61494f83967f0235441cf7e69f6c/include/globals.h#L125-L129>: if USE_MATRIX is not defined to 1 by line 125 at the time of writing, USE_LEDSTRIP is defined to 1 instead. Depending on which one of the two is defined, LEDMatrixGFX is compiled in and used to take care of the actual drawing to the HUB75 panel, or LEDStripGFX is used instead to drive the WS2812 strip(s)/grid(s). There is one variation to this, which is when HEXAGON is defined to 1. HEXAGON is an extension of USE_LEDSTRIP, which comes with it's own GFX class HexagonGFX. That is a subclass of LEDStripGFX - which means it also drives a WS2812 device - but implements the different geometry that comes with a hexagon shape. Driving both a HUB75 panel and a WS2812 grid may be technically possible, but the codebase currently doesn't cater for it. It's not just the either/or in globals.h; the code takes as a premise that there is one list of effects (managed by EffectManager) that is being displayed on one type of graphics device (LEDMatrixGFX, HexagonGFX or LEDStripGFX). I'd say there is currently no inherent support for non-oblong shapes composed of smaller grids. As was done with HEXAGON, one would probably add a new LEDStripGFX subclass to deal with the specifics of whatever shape one would like to use. This could potentially be generalized into a GFX class that can handle different "tetris-like" compositions, but I haven't even begun thinking that one through. The contents of platformio.ini have indeed been composed in part by copying and pasting - as globals.h has been as well. I'd say it makes sense, because some project configs in globals.h are enabled for different chips/boards in platformio.ini. That said, a major overhaul of platformio.ini has already been done some time ago, by yours truly. That introduced the separation of device configurations from project configurations ("envs"), the introduction of "feature configs", etc. Smaller updates have been made since, and PR #370 <#370> that is now open includes fixes for some glitches that have been introduced in recent times. I'm not exactly sure what makes you conclude that platformio.ini is out of sync with reality in the broader sense. I do know I can't establish by trying, because I only have the gear for two projects: Mesmerizer on the Mesmerizer board, and Spectrum on the M5StickC Plus. I know both of those work. — Reply to this email directly, view it on GitHub <#372 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF6W77P2PS26MASEBJTXRY6QZANCNFSM6AAAAAA2VAX2TY>. You are receiving this because you are subscribed to this thread.

[robertlipe]

You're asking a lot of questions in your post. I've read them all, but I'll only respond to the points I think I can:

Indeed. When I commit to get my head around something, I really commit. Thank you and sorry.

- Maybe I'm misreading your first sentence, but the rest of the config for Mesmerizer doesn't also run a 48x16 grid. Other configs can, and for instance Spectrum does, but that doesn't also run a HUB75. That's helpful. That means the comment

<https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/86418d267e8142ed7cb1e90e4d3059d69dba946d/include/globals.h#L451> is wrong. That comment block appears in globals.h five times. Doesn't that also mean that setting RING_SIZE, FANS, BANDS, and such inside the MESMERIZER config is distracting? (I get they may not be USED, but they're distracting - evidenced by my confusion.)

- At the moment it's an either/or thing when it comes to what you drive. You either choose to drive a HUB75 panel by defining USE_MATRIX to 1 - which is now always done in the platformio.ini build config -, or you drive WS2812 strips/grids. This is sorted out towards the top of globals.h <https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/2fa544653a9a61494f83967f0235441cf7e69f6c/include/globals.h#L125-L129>: if Aha! That's an additional knob I hadn't even considered. I thought

globals.h was THE knob and couldn't get my head around why USE_MATRIX wasn't set inside #if .. MESMERIZER. Now I've learned that there are two globals config thingies. That's ... not obvious. Should platform.ini perhaps be the boss of "you are this board" (-DMESMERIZER) and config.ini be the worker (#if MESMERIZER/#define USE_MATRIX) ? Imagine a world where you have two build systems (e.g. cmake). Now you have hardware configuration split between the build system (platform.ini) and config.h. Even if you don't imagine that, maybe USE_FOO would be more consistent moved into config.h I'm willing to do the move if you agree that's a good thing.

- Depending on which one of the two is defined, LEDMatrixGFX is compiled in and used to take care of the actual drawing to the HUB75 panel, or LEDStripGFX is used instead to drive the WS2812 Got it now. They're totally mutually exclusive. You can have HUB

(USE_MATRIX) OR WS2812 (USE_STRIP) but never both at once. Line 125 responds to that, but doesn't really enforce it, but now that I know that's just a non-goal to support, that's OK. Remember when I was fussing about the definition of MATRIX being unclear w.r.t a grid of 2812's vs a HUB75? This is probably the root of that confusion.

- strip(s)/grid(s). There is one variation to this, which is when HEXAGON is defined to 1. I have a HEXAGON board on my desk, so that's in my future, too. Good to

know.

- HEXAGON is an extension of USE_LEDSTRIP, which comes with it's own GFX class HexagonGFX. That is a subclass of LEDStripGFX - which means it also drives a WS2812 device - but implements the different geometry that comes with a hexagon shape. Got it. That's not UNlike the grids of 2812's that you showed in your

recent photograph. It wouldn't have been UNreasonable to consider those a MATRIX, but I now see that's just not how it works. It's just a terminology trip-up.

- Driving both a HUB75 panel and a WS2812 grid may be technically possible, but the codebase currently doesn't cater for it. It's not just the either/or in globals.h; the code takes as a premise that OK, non-goal. I'll quit trying to make that make sense. - I'd say there is currently no inherent support for non-oblong shapes composed of smaller grids. As It's a weird case. So no recreating something like this

<https://plsn.com/site/wp-content/uploads/6_GenesisPhotobyTreatment.jpg>. (Here, they're just subsetting the panels, but the panels actually did independently move in concert, making it clear they were separate. And, yes, I get the project isn't trying to be a multi-$M stage lighting - it was just a convenient picture.)

- The contents of platformio.ini have indeed been composed in part by copying and pasting - as globals.h has been as well. I'd say it makes sense, because some project configs in globals.h are That's increasingly clear. Even if there are some dingleberries left over

in doing so (like RINGS in Mesmerizer), please consider my request to make the comments at the top describing them accurate. I think the misleading block there really put me into a tailspin.

- enabled for different chips/boards in platformio.ini. That said, a major overhaul of platformio.ini has already been done some time ago, by yours truly. That introduced the separation of device I get that managing growth is hard. OTOH, it's a good problem to have! - I'm not exactly sure what makes you conclude that platformio.ini is out of sync with reality in the I didn't really know about platform.ini when working through this. My link

was to globals.h and I think we've just concluded that: #elif MESMERIZER // This project is set up as a 48x16 matrix of 16x16 WS2812B panels such as: https://amzn.to/3ABs5DK // It uses an M5StickCPlus which has a microphone and LCD built in: https://amzn.to/3CrvCFh // It displays a spectrum analyzer and music visualizer is indeed out of touch, right? Mesmerizer isn't a 48x16 grid at all and is never 2812's. I now know: - globals.h and config.ini both exist and both control features, not just builds. (And that the comments, as they stand, speak untruths.) - mixing HUB and 2812 in the same build is a non-goal. - supporting > 1 rectangle (hexagon) is a non-goal. This means that supporting multiple HUB75 panels of different shapes is right out. (64x64 remains to be studied.) - supporting sparse pixel grids (beyond hexagon) is a non-goal This was hugely helpful. Thank you.

…

Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/372/comments/6527296 @github.com>