Es un formato para intercambio de datos entre consolas de iluminación. Aunque sea posible su manipulación en cualquier ordenador (se trata de código ASCII), recordar que no es esa su función inicial.

Organización responsable del estándard

Más información

Hay una cuestión que muchos técnicos se plantean con frecuencia

¿Porqué no puedo intercambiar los datos de mi Show entre distintos controles de iluminación? La respuesta es que cada mesa emplea unos formatos específicos para guardar su contenido. En ocasiones, hasta mesas de la misma marca producen archivos incompatibles entre sí. En MIDI, ocurría lo mismo: cada secuenciador guardaba los datos a “su manera”… hasta que se ideó el Standard MIDI File, un formato único que puede ser reconocido por cualquier máquina MIDI que cumpla dicho Standard (actualmente, todas). Las ventajas son evidentes; pero también hay ciertas limitaciones, pues el Standard sólo recoge las bases que han de ser intercambiadas, obviando las características específicas de un secuenciador en particular. Así, es normal que podamos salvar los datos en 2 formatos:

  1. Basado en el Standard, que nos asegura compatibilidad con otras máquinas para las características básicas (debiendo prescindir de las específicas).
  2. El propio de la marca o producto con el que trabajemos. Normalmente es más rápido a la hora de cargar / salvar y contempla cada detalle o implementación en el producto. Pero es totalmente incompatible con el resto de máquinas.

Esto es normal, pues cada aparato resuelve su forma de actuar de una manera determinada, tiene su propio Setup y sus propias características adicionales y particulares, etc. Sólo la base de los datos es lo que se puede compartir. Volviendo a la iluminación, en la actualidad debemos considerar los siguientes casos:

  • El dispositivo para almacenar los datos difiere de unos sistemas a otros: Disquete (con formato DOS o no), Tarjeta de memoria (diversos tipos de interfaces, diversos tipos de tarjetas y variada capacidad de las mismas).
  • Formato de datos. Aún partiendo de un mismo dispositivo de almacenaje, está la forma en que los datos se introducen en él. Hay aparatos que generan varios archivos para un sólo Show, otros sólo uno. Algunos son editables mediante un procesador de textos, otros en absoluto, etc.
  • Programas traductores. Algunas marcas pueden suministrar pequeños programas informáticos que aceptan diversos formatos que puede traducir o convertir, acomodándolos según las características de los aparatos origen y destino. Normalmente todos los formatos permitidos pertenecen a la misma marca y se ofrece como herramienta de compatibilidad entre sus propios productos, que con el paso del tiempo (a veces muy poco), han ido evolucionando y separándose entre sí.
  • Datos en formato ASCII Light Cue: Después se hablará de él, pero es el equivalente en iluminación del Standard MIDI File que se ha comentado anteriormente.
  • Datos en formato ASCII Light Cue + Formato propietario: Ofrectodas las ventajas disponibles hoy día, pues permite salvar los datos básicos en compatibilidad con otros aparatos y además salvarlos independientemente para su formato específico, recogiendo todas las características propias de cada máquina.

Las medias verdades del ASCII Light Cue. Aquí surgen nuevas cuestiones: ¿Cuantas mesas de iluminación implementan ALC? Las que lo implementan, ¿en qué grado lo hacen?, etc.

Breve resumen de implantación del ASCII Light Cue

A título orientativo, recogemos lo más significativo de la norma, para analizar algunas de sus posibilidades como método de intercambio real entre diferentes fabricantes: Sólo está definida la interpretación de la información, NO el mecanismo de transmisión ni el medio de almacenaje; es decir, se puede cumplir la norma para una transmisión serie, para un soporte magnético, etc. (lo más normal para el intercambio es un fichero de texto grabado en disquete formateado bajo DOS). Se genera un único “chorro de datos” por Show y el contenido se podrá editar mediante cualquier programa de tratamiento de textos u hoja de cálculo (código ASCII). La interpretación ha de ser secuencial y no es aceptado un acceso aleatorio a la información. Es posible determinar el grado de adecuación de los datos sobre los equipos, estableciendo unas alternativas de interpretación y excepción para cuando se produzcan conflictos (por ejemplo, si tenemos varios patch *** y la mesa de destino sólo acepta uno, cuando hay más canales que los que la mesa receptora puede controlar, etc.). Hay catalogados 3 tipos de mensajes: información, aviso y error, con una serie de códigos cada uno (algunos genéricos, otros específicos y otros personalizables) y también hay 3 niveles de cumplimiento para su interpretación y presentación al usuario (códigos de 2 cifras, códigos de 4 cifras y mensajes de texto). Al nivel de interpretación de datos, se establecen unas tablas bidireccionales de conversión entre los valores en % (100 niveles), normalmente empleados para representación en pantalla y su correspondencia con los valores entregados en la salida DMX (256 niveles), de forma que los datos intercambiados, sean tratados / representados de igual manera. Los datos numéricos pueden estar en decimal (0-100%) o en hexadecimal (256 pasos), con 2 o 4 dígitos hexadecimales (0-9 y A-F) y debe ir precedido por una H (90%: HE6). Y también existe la posibilidad de incluir cualquier tipo de comentario, ya que al cargar la información, lo escrito tras “!” es ignorado. La estructura básica de los datos se encuentra dividida en 3 partes:

  1. ENCABEZADO

    • MANUFACTURER, o descripción del fabricante.
    • CONSOLE, o descripción del modelo de consola.
    • IDENT, o identificación de la versión del STANDARD ASCII Light Cue implementada (actualmente, la 3.0).
    • CLEAR. Es un comando de carga, y nos indica si borrar (parcial o totalmente) los datos existentes en la consola antes de la carga. Ya que está permitida un borrado total (ALL) ó parcial de los datos (SUBMASTER, PATCH, CUES, GROUPS ó $M-SPECIFIC).
    • PATCH# #’
    • SET. Para establecer la configuración de la consola (canales de mesa, dimmers, patch por defecto, parámetro específico, etc.)
    • $M-SPECIFIC, $ATTRIBUTES, $MIDI. Aspectos específicos del modelo, que otros fabricantes no están obligados a contemplar.

  2. DATOS

    • PALABRAS PRIMARIAS. La estructura básica de datos viene definida por unas palabras clave, que identifican conceptos primarios en iluminación:
      • CUE: Referente a la memoria, preset, cue o escena.
      • GROUP: Referente a los grupos o preselecciones.
      • SUB # #’: Referente al contenido de páginas y masters -controllers, subgrupos- En principio la estructura responde a los números de página # y subgrupo #’.
      • $M-SPECIFIC, $EFFECT: u otros definidos por el fabricante, y que no otros fabricantes no están obligados a tener en cuenta.
    • ATRIBUTOSde las palabras primarias. Los atributos asociados profundizan en la definición completa de estos conceptos básicos:
      • TEXT: Es el texto asociado a cualquiera de las estructuras básicas.
      • UP #, #’ (up #, delay #’) Son los tiempos de entrada y delay de entrada.
      • DOWN #, #’ (down #, delay #’) Son los tiempos de salida y delay de salida.
      • CHAN #@#’ #@#’ (Contenido: canal # a #’%, canal # a #’%)
      • FOLLOWON # Tiempo al siguiente CUE (sólo con CUES) este tiempo no se corresponde con el tiempo que transcurre entre el final de un fundido y el comienzo del siguiente, es el tiempo entre fundidos. (Las consolas que no adoptan este sistema de medida se verán obligadas a “recalcular” este tiempo o ignorarlo).
      • LINK # Enlaza este CUE con el indicado (sólo con CUES)
      • PART. Partes de tiempo (sólo con CUES y GROUPS)
      • $$M-SPECIFIC. Datos específicos del fabricante.

  3. FINAL DEL ARCHIVO

    • ENDDATA.

Conclusión

Como se puede apreciar, hay numerosos conceptos en iluminación que han quedado fuera de estas bases, tales como los chases, los efectos, las secuencias o crossfaders, y todo es debido a que cada fabricante trabaja con normas propias estas estructuras complejas. En resumen podemos ver como el ALC va perdiendo efectividad según nos alejamos de la iluminación más convencional: el teatro. Una consola de iluminación convencional podrá aprovechar un % muy elevado de cualquier fichero ALC, principalmente las memorias (cues) con sus canales/niveles, tiempos y texto asociado, así como el patch o patchs (dentro de los cuales tampoco se hará referencia a curvas de dimmer u otros parámetros asociados). Utilizar este formato de datos en consolas de iluminación para robotizados, no nos aporta grandes ventajas, ya que en ALC no existen las estructuras básicas de “móvil” o “cambio de color”. Esto obligaría a los fabricantes a adoptar un método de interpretación de PALABRAS ESPECIFICAS, diferente para cada MANUFACTURER y CONSOLE, lo cual se aleja bastante de la idea de “estándar” que se pretende conseguir con ALC. (La versión 3.0 de ALC data de marzo de 1992).