Què és Lumware

Vaig començar volent fer parpellejar uns LEDs. He acabat dissenyant una família de software. Aquest post explica com una tira de cent llums es va convertir en una idea de producte amb tres cares.

El context

Una tira NeoPixel és una llista de LEDs RGB on cada llum és direccionable individualment: pots dir a la llum número 47 que sigui taronja sense que això afecti la 46 ni la 48. Físicament és una cinta flexible amb tres cables (alimentació, terra, dades) i un microcontrolador minúscul dins de cada LED.

Hi ha mil tutorials per fer-les parpellejar. Pràcticament tots paren al mateix lloc: un sketch d’Arduino amb una animació codificada a dins, una paleta fixa, i potser un botó. Bonic com a prova; insuficient com a producte.

Si vull que la tira mostri una imatge o un vídeo —res que no estigui escrit prèviament al firmware— el sketch sol no n’hi ha prou. El microcontrolador no té memòria per guardar fotos, i tampoc no té com llegir-les des d’un disc.

El que falta és un host: un ordinador que faci la feina pesada (descodificar imatges, redimensionar-les, triar colors per a cada LED) i que enviï a Arduino només el resultat final, frame a frame, en temps real.

La decisió

Vaig partir el sistema en dues meitats clares:

• Host (Python): llegeix la mèdia, prepara els frames, els empaqueta i els envia per USB sèrie.
• Firmware (Arduino): rep frames, els pinta a la tira amb el timing que els WS281x exigeixen, i no fa res més.

Aquesta separació és la primera decisió de marca. El nom Lumware ve d’aquí: lum (llum) + ware (software). És el host. No és la tira. La tira és hardware d’un fabricant; Lumware és el que la fa servir.

Un cop separat host i tira, va aparèixer una segona idea: si el host pot llegir imatges i vídeos, també pot llegir sensors (càmera, micròfon, MIDI), o rebre el resultat d’un motor 3D com Unity. Tres dataflows diferents, mateixa idea base: alguna cosa produeix píxels, alguna cosa els pinta.

D’aquí surt la família:

• Lumware (aquest repo, el flagship): host → strip. Imatges, vídeos i renderitzats acaben a la tira.
• Lumware Capture: sensor → host. Una càmera o un micròfon alimenten un host que decideix què fer amb el senyal.
• Lumware Stage: unity ↔ strip. Unity envia frames i rep esdeveniments de la tira (toc, posició) en bidireccional.

Cada producte viu al seu propi repositori. Comparteixen marca (paleta spectrum, tipografia Geist) i vocabulari (frames, transport, host), però no codi. No tot ha de ser un monorepo.

Per què tres repos i no un. Un monorepo m’obligaria a acoblar releases. Lumware Stage depèn de Unity, que té cicles propis; Lumware Capture depèn de drivers de sensor que canvien sovint. El flagship és el més estable i no vull que un canvi a Unity pari els seus PRs. Comparteixen contracte (el frame binari), no implementació.

Què no és Lumware

Per ser explícit:

• No és automatització de la llar. Lumware controla la tira, no l’habitació.
• No és mood-lighting. Tots els valors són mesurats, no intuïts.
• No és un servei al núvol. Tot viu a la LAN — sense servidors externs, sense telemetria.
• No depèn de hardware. El transport virtual arrenca sense Arduino: els frames van directament al canvas del dashboard.

El que ve

Al pròxim post explico com es passa d’un script de 200 línies a un producte amb estructura, marca i traça. La peça invisible que va permetre que la idea de la família existís: no n’hi ha prou amb tenir-ho funcionant, cal poder-ho explicar. Què va canviar el dia que vaig decidir tractar el codi com un producte i no com una prova?