Help needed developing a "matrix controller" for my Lumen Lights

Sizes and Measures

Ok, let me elaborate my background deliberations about the size a bit.

First of all, I less design single lights, but more of a genuine light-construction-system. Meaning though every light may be unique in lighting and appearance, their building follows (more or less) the same procedures with similar parts (In a post MVP phase I want to have it so modular that parts between models can be interchanged → e.g. upgrade your light with another stone and a new outer frame, give the “old” parts to a friend who now only needs an inner frame to build an own light for himself). Furthermore the production design would split up into a pre-assembly-phase (where parts are produced) and a simple-as-possible assembly phase where the light is put together, so that for logistical reasons lights are sold (and later sent) as a construction kit.

The light size itself (and such the controller) is specified by the common stone sizes (10x10, 10x20, 20x20) that perfectly fit the common matrix sizes (8x8, 8x16, 16x16) that - on an alu plate - will be put on top of the controller box.
The controller/PCB itself should be of 9-9,5cm length (10cm - 2x 0,25-0,5cm for the thickness of the box)

Besides these three frame-design models (prio 1) I want to use the controller also within a socket-design (prio 2), where a central alu square is routing LEDs and cables. Thats where the 4cm originated from (2cm for a central square = 2 x 4cm free space at the sides). 10cm x 4cm (instead of 10x10 with a central whole) was originally chosen because of the needed space for a power supply. In a 20x10 light these 16x10 leftover space would be sufficient for a powerbank or LiPo.

But for the sake of the practicability I would accept a trade-off here. For both the 10x10 and 20x10 light the PSU/battery could be attached below the controller, as they look fine with a higher frame. The 10x10 stone is on a 10 cm height frame, the 20x10 stone currently on a 4 cm high frame. For aesthetical reasons I want to keep the golden-cut: 5cm high stone on 10cm high 10x10 frame, 4cm high 20x10 stone on -currently- 4cm high frame (normally stones are either 5 or 2,5cm high, this one is 3-5cm high due to its raw structure). An exception here is the 20x20 light that currently has a 2,5cm high frame. First this looks pretty neat with a 5cm high stone. Second as this light is also been thought of a vertically wall-mountable-light (with a 2,5cm high stone properly attached, but that mechanism is another story). Space for any kind of PSU/battery on the same level shouldnt be a problem, too. So the height (of the box) shouldnt overextend 2cm (+ 0,5cm attached LED matrix = 2,5cm high 20x20 frame) if doable.

Another variable is the third (not yet completely specified) shelf-design that the new FrostFire is following. But clear here is, that the frame depth shouldnt exceed 10cm. With space for the stone calculated there is a leftover of 7cm. Ways to go from here: 1)limit controller overall size to 10x7, 2) make a slightly different controller.

Oh… One crucial aspect I just recognized… Problem: For the socket design all I/O stuff has to be at the back 10cm side (given a 10x7 size). But for the shelf design I/Os wouldnt be reachable if directed to the back, so it needs some kind of side access. In theory this could be solved with a 7x7 controller, but thats hardly limiting the space and complicates things again, so I am a bit unsure and have to think about it. A spontaneous possible solution: As socket and shelf lights are not focused on audio-reactivity, the core controller could be 7x7 with the option to add a 3x7 SR module for the frame-models. Or as another trade-off I could install a 10x10 controller in a standing way, not elegant but practical.

As mentioned, this would be the ultimative all-in-one solution that would allow me to build dozens of different but similar lights based on 3 designs that all are based on one controller. A visualized jack-of-all-trades would be sth. like this one:

Thanks for reading (and thinking…)
Kelvin