Cómo utilicé las herramientas de código abierto para construir un sistema de iluminación para teatros

| |

COMPARTE EL ARTÍCULO!!!

Las cosas que hacemos por la familia, ¿eh? A veces me pregunto por qué me lo hago a mí mismo, ya que esta no es la primera vez que mi perfeccionismo me ha llevado a hacer mucho más trabajo que una tarea originalmente requerida.

Mi suegro se me acercó hace poco más de un año, porque la iglesia a la que asiste estaba montando una producción de Les Misér ables. Para hacerlo más grande y mejor que el año anterior, había comprado algunas luces y un escritorio de iluminación y esperaba que yo pudiera operarlas. «¡Claro!» Dije. «¿Qué tan difícil puede ser?» Luego describió su visión para una de las escenas: Una gran batalla con luces parpadeantes; ya sabes, ¡muy emocionante! «Genial», dije y acepté sin querer.

Explorar el hardware abierto

  • ¿Qué es el hardware abierto?
  • ¿Qué es Frambuesa Pi?
  • ¿Qué es un Arduino?
  • Nuestros últimos artículos de hardware abiertos

Me senté por primera vez a trabajar en el escritorio de iluminación que había comprado: un pequeño, de gama baja, multicanal DMX-512. Tenía capacidad para cientos de escenas, desvanecimiento, e incluso una buena jog wheel. Estaba emocionado! A pesar de que el manual era obviamente una mala traducción y que el escritorio requería una verdadera procesión de pulsaciones de botones sólo para conseguir que hiciera algo, perseveré. Creé una escena similar a una batalla, pensando que era inteligente empezar con la parte que yo creía que sería la más difícil. Se lo mostré a mi suegro y vi su cara decepcionada. «Esto es sólo una prueba», me apresuré a señalar. «La cosa real se verá mucho mejor, por supuesto.» Él se alejó. D$0027oh.

Empecé a pensar en los problemas de la escena. No fue lo suficientemente aleatorio…. necesitaba parecer más aleatorio. Decidí que si podía generar suficientes escenas en las que las luces se movieran por ciertos caminos, podría desvanecerme rápidamente entre ellas usando el fader incorporado, y todo estaría bien. ¿Verdad? Generar la información de la escena fue difícil. Fue en ese momento cuando conseguí mi primera herramienta de código abierto en el trabajo: ¡Blender!

Utilicé las curvas de animación de Blender para jugar con las luces de una escena y generar un aspecto convincente de batalla. Luego escribí algunos scripts de Python dentro de Blender para exportar los movimientos a un CSV, dándome datos de columna para cada escena, que luego podía programar en el escritorio. Finalmente sentí que estaba llegando a algo.

Si no fuera por el hecho de que sólo programar esta cosa era suficiente para inducir el estrés (además de la sensación de que me estaba causando una lesión por estrés repetitivo), y que un solo deslizador se suponía que controlaba una duración de tiempo de 0.2s a 30s (quiero decir, ¡vamos realmente?!), los resultados eran menos que estelares. Simplemente no se veía bien. Suspire. Si tan sólo tuviera el control total sobre ella, pensé. Si tan sólo pudiera programar estas luces usando Python.

Mi mente se desvió, y una visión de un tipo relajándose en una tumbona en una playa programando su iluminación DMX-512 en Python pasó flotando. «Parece tan feliz», pensé. Debo tener lo que él tiene.

Tuve una charla con mi cuñado, un compañero entusiasta de la tecnología que, debo añadir, ya había empezado a mezclar el sonido. Decidimos que valdría la pena invertir en la compra de una interfaz USB DMX-512. Compramos uno por probablemente la mitad del costo del escritorio, y comencé a explorar opciones para el control de DMX-512 en Linux. Encontré algunas aplicaciones, pero la mayoría de ellas parecían estar basadas en escenas estáticas desde el principio. También tenía la sensación de que este proyecto era algo que se expandiría, crecería, y sufriría de una pérdida de alcance.

Al no encontrar ninguna aplicación que satisficiera mis necesidades tanto de disponibilidad en mi sistema operativo como de funcionalidad, decidí escribir la mía propia. Encontré la Arquitectura de Iluminación Abierta (OLA) y, después de algunos ajustes con los módulos de listas negras, tenía un pequeño script Python que enviaba datos a las luces y las encendía y apagaba. Estaba extasiado. Ahora sólo tenía que escribir un sistema completo para lograr el sueño.

Empecé de a poco, considerando lo que era absolutamente necesario. Quería un formato común para almacenar las escenas. Una cosa que me molestaba del escritorio de iluminación era la falta de respaldo. Si el escritorio sufriera de alguna malfunción, todas mis preciosas escenas podrían ser borradas. Horas y horas de trabajo desperdiciadas. No. No es una opción. Elegí el formato abierto YAML para mis escenas. Lo usaba mucho en mi trabajo de día, y parecía encajar en mi presupuesto.

Muy pronto tuve la habilidad de desvanecerme entre dos escenas de una manera sana, interpolando entre cada valor de canal para cada luz. Esto significaba que si el canal de brillo de la luz 1 estaba al 50% en la escena 1 y al 75% en la escena 2, entonces el software aumentaría linealmente de uno a otro durante el período de tiempo especificado. ¡Excelente!

Entonces empecé a añadir modificadores a los canales. Esto era algo que había visto en Blender. Los canales animados de datos (una curvatura de brazo a hueso, una traslación del eje x de la cámara) podrían tener fotogramas clave, pero también podrían tener modificadores aplicados al canal para generar cosas como ruido u otros efectos. Añadí unos pocos modificadores rudimentarios a mi proyecto, y pronto tuve cos/sin dando a los canales de inclinación/bandeja de la luz un movimiento circular. Luego añadí modificadores de waypoints usando curvas spline para permitir al canal ir suavemente a diferentes valores en diferentes puntos en el tiempo. Todo progresaba constantemente.

Trabajar en las luces sin estar en la iglesia fue un reto. Era difícil visualizar cómo eran las escenas, así que volví a Blender, añadiendo una simple API HTTP a la aplicación y pidiendo a Blender que consultara y actualizara rutinariamente las luces que había configurado en una escena. Esto me permitió hacer una demostración de mi iluminación y ver lo que estaba sucediendo.

Demostración de la visualización temprana

Una máquina de humo fue añadida al set. «¿Puedes controlar eso también con lo tuyo?» Me lo pidieron. «Sí, supongo», respondí. Debido a la interfaz de usuario muy limpia y minimalista, sólo había controles de escena, sin faders de canal para las luces. Por lo tanto, controlar el humo significaba inculcar algunos valores en las escenas. El humo no es sólo una mercancía que no es libre, sino que los artistas tienden a disgustarse cuando los inundas con humo mientras actúan, todo en nombre de las pruebas. Podría haber usado uno de los modificadores de waypoints pero no quería que se disparara cada vez que entraba en esa escena.

Necesitaba otra forma de controlarlo. Mi mente se preguntaba. «¿No sería genial si pudiera usar un WiiMote para hacer eso?» Entonces me di cuenta. «¿Por qué diablos no puedo?» Me dirigí a la biblioteca de cwiid, cogí un mando de WiiMote que estaba en la sala de estar y le di un buen uso. Pronto el canal de las máquinas de humo tuvo un modificador de WiiMote que me permitió levantar el mando para empapar a los actores en una espesa nube de bondad de humo.

La inclinación del controlador está ligada al brillo general de las luces 1,2,3,4. El balanceo del controlador está ligado a la cantidad de azul en las luces 1,4 y también a la inclinación de las luces 2 y 4.

Dejándome llevar, añadí la generación dinámica de la interfaz de usuario de GTK de los deslizadores de canal desde la configuración de YAML, lo que significaba que podía cambiar a diferentes canales y anularlos. Es bueno que lo haya hecho, ya que los artistas nunca parecen usar el mismo micrófono todas las noches. Lección aprendida. Ahora podía reaccionar a esos cambios y subir y bajar las luces manualmente, como si estuviera usando el escritorio.

Tres actuaciones fueron y vinieron. La escena de la batalla, inundada de pecado/cos y el nuevo modificador aleatorio, se veía espectacular. Junto con el audio que mi cuñado montó, nos sentimos muy bien al respecto.

Demostración de la escena de batalla

Adelántalo a un año después. Tengo una actuación que hacer mañana, y mi cuñado acaba de preguntarme: «¿Hay alguna forma de hacer que tu sistema reproduzca los sonidos para que no tengamos que activarlos juntos? «Por supuesto», respondo. Ahora puede, gracias a GStreamer. También puede controlar un canal basado en la amplitud de la onda, lo que me permite sincronizar las explosiones de la escena de la batalla con los movimientos de iluminación. ¡Gracias, SciPy!

Entonces, ¿cuál es la comida para llevar? Sin el código abierto nunca, nunca, nunca habría terminado este proyecto. Habría tenido que escribir o comprar controladores WiiMote, controladores DMX-512, enrutamiento DMX y backends de control, software de visualización, estándares de configuración, generación de UI. El código abierto me dio tres cosas, todas ellas de un valor incalculable.

  1. Me dio acceso a todas estas cosas para poder concentrarme en escribir el pegamento que las unió todas.
  2. Me dio la capacidad de actualizar y añadir continuamente a mi proyecto frankenproject, que sin duda algún día reescribiré y publicaré.
  3. Eso hace feliz a mi suegro… por ahora.

Sin el código abierto, me habría quedado atascado en un desorden repetitivo, causado por el estrés y las lesiones, murmurando algo sobre la necesidad de mantener presionado el botón de escena durante tres segundos antes de presionar una combinación del botón de programa y el botón de borrar.

Creo que el código abierto me salvó la vida y me dio un buen paseo mientras estaba en ello.

COMPARTE EL ARTÍCULO!!!

Previous

PressurePen: Un palpador de código abierto y sensible a la presión

Especial Día del Arduino: Introducción a las etiquetas RFID

Next

Deja un comentario

shares