Qué es Lumware

Empecé queriendo hacer parpadear unos LEDs. He acabado diseñando una familia de software. Este post cuenta cómo una tira de cien luces se convirtió en una idea de producto con tres caras.

El contexto

Una tira NeoPixel es una lista de LEDs RGB donde cada luz es direccionable individualmente: puedes decirle a la luz número 47 que sea naranja sin afectar a la 46 ni a la 48. Físicamente es una cinta flexible con tres cables (alimentación, tierra, datos) y un microcontrolador minúsculo dentro de cada LED.

Hay mil tutoriales para hacerlas parpadear. Prácticamente todos paran en el mismo punto: un sketch de Arduino con una animación escrita a mano, una paleta fija y quizás un botón. Bonito como prueba; insuficiente como producto.

Si quiero que la tira muestre una imagen o un vídeo —algo que no esté escrito previamente en el firmware— el sketch solo no basta. El microcontrolador no tiene memoria para guardar fotos, ni manera de leerlas desde un disco.

Lo que falta es un host: un ordenador que haga el trabajo pesado (decodificar imágenes, redimensionarlas, elegir colores para cada LED) y que envíe a Arduino solo el resultado final, frame a frame, en tiempo real.

La decisión

Partí el sistema en dos mitades claras:

• Host (Python): lee el medio, prepara los frames, los empaqueta y los envía por USB serie.
• Firmware (Arduino): recibe frames, los pinta en la tira con el timing que los WS281x exigen, y nada más.

Esta separación es la primera decisión de marca. El nombre Lumware viene de ahí: lum (luz) + ware (software). Es el host. No es la tira. La tira es hardware de un fabricante; Lumware es lo que la usa.

Una vez separados host y tira, apareció una segunda idea: si el host puede leer imágenes y vídeos, también puede leer sensores (cámara, micrófono, MIDI) o recibir el resultado de un motor 3D como Unity. Tres dataflows distintos, misma idea base: algo produce píxeles, algo los pinta.

De ahí sale la familia:

• Lumware (este repo, el flagship): host → strip. Imágenes, vídeos y renderizados acaban en la tira.
• Lumware Capture: sensor → host. Una cámara o un micrófono alimentan a un host que decide qué hacer con la señal.
• Lumware Stage: unity ↔ strip. Unity envía frames y recibe eventos de la tira (toque, posición) de forma bidireccional.

Cada producto vive en su propio repositorio. Comparten marca (paleta spectrum, tipografía Geist) y vocabulario (frames, transport, host), pero no código. No todo tiene que ser un monorepo.

Por qué tres repos y no uno. Un monorepo me obligaría a acoplar releases. Lumware Stage depende de Unity, que tiene ciclos propios; Lumware Capture depende de drivers de sensor que cambian a menudo. El flagship es el más estable y no quiero que un cambio en Unity pare sus PRs. Comparten contrato (el frame binario), no implementación.

Qué no es Lumware

Por ser explícito:

• No es automatización del hogar. Lumware controla la tira, no la habitación.
• No es mood-lighting. Todos los valores son medidos, no intuidos.
• No es un servicio en la nube. Todo vive en la LAN — sin servidores externos, sin telemetría.
• No depende del hardware. El transport virtual arranca sin Arduino: los frames van directamente al canvas del dashboard.

Lo que viene

En el próximo post explico cómo se pasa de un script de 200 líneas a un producto con estructura, marca y traza. La pieza invisible que permitió que la idea de familia existiera: no basta con tenerlo funcionando, hay que poder contarlo. ¿Qué cambió el día que decidí tratar el código como un producto y no como una prueba?