Radio Breve®

Qué es Radio Breve

Radio Breve es la emisora de Breve: una señal de música continua, con anuncios intercalados y mensajes por altavoz, que la oficina controla desde la misma aplicación con la que ya factura, compra y cobra. Para escucharla basta un celular, una bocina y el enlace de la señal, de forma tal que no hace falta instalar nada ni comprar equipos especiales. Es también un proyecto exploratorio, un laboratorio para que IMS pruebe tecnologías nuevas en un caso real y acotado antes de llevarlas al resto de la plataforma, pues lo que aprendamos aquí, tanto lo que funcione como lo que no, se convierte en la forma de construir Breve en adelante.

Para qué se hizo

Radio Breve cumple tres propósitos a la vez, y aunque la funcionalidad es útil por sí misma, su valor principal está en lo que nos permite probar y mostrar. El primero es probar tecnologías nuevas (la emisión de audio en vivo, la voz sintética natural, el análisis musical y la comunicación en tiempo real) en un caso real y acotado, antes de llevarlas al resto de Breve. El segundo es demostrar nuestra capacidad de innovar, pues es una pieza visible que muestra a clientes y aliados que en IMS no solo mantenemos un sistema administrativo, sino que diseñamos y construimos aplicaciones modernas desde cero. El tercero es iniciar la renovación de Breve: es el primer módulo de la aplicación construido por completo con Carbon Design System, el sistema de diseño al que migraremos toda la plataforma, y la primera vez que el equipo completo trabaja con él.

Cómo funciona

A diferencia de una lista de reproducción, que cada teléfono toca a su manera, Radio Breve es una emisora: una sola señal, generada en el servidor, que suena igual en la aplicación, en una página web, en un celular o en una bocina inteligente.

1. La oficina

   Carga canciones, playlists y anuncios, y deja mensajes por altavoz desde el menú Radio.

2. Breve decide

   En cada corte entra lo de mayor prioridad: mensajes, anuncios, menciones y, si no toca nada, música.

3. El motor emite

   Une las canciones, intercala los anuncios, baja la música bajo la voz y emite una señal continua.

4. Donde se escucha

   La aplicación de Breve, un celular con su bocina, una página web o cualquier equipo de sonido.

• Música. Las canciones se analizan al subirlas: tempo, tonalidad, energía y dónde canta la voz. Con eso Breve sabe qué canciones combinan entre sí y en qué punto exacto unirlas, de forma tal que una entre mientras la otra se despide, sin silencios ni saltos bruscos.
• Anuncios. Entran en los cortes, y no en cualquiera: Breve los coloca en las uniones donde dos canciones combinan menos, que es justo donde el oído agradece una pausa. Hay reglas para no saturar, pues un anuncio repetido diez veces en una jornada deja de informar y empieza a molestar.
• Menciones. Un «¡Radio Breve!» breve, dicho encima de la música en un tramo donde no hay voz cantada, con la música un poco más baja mientras suena.
• La voz como interfaz. Primero el dictado en los campos de texto; luego avisos de tareas y casos por la emisora, avisos personales en el celular y, por último, conversar con Breve con la voz.
• Mensajes por altavoz. Grabados, escritos o repetidos de los anteriores. La oficina ve cuánto falta para que salga el mensaje y puede adelantarlo con Reproducir ahora.

La señal en vivo

Lo que distingue a Radio Breve de una lista de reproducción es que no hay un teléfono decidiendo qué toca: en el servidor se genera una sola señal continua, ya mezclada, y todo el que se conecta escucha lo mismo en el mismo momento. Es, a fin de cuentas, cómo funciona cualquier emisora, con la diferencia de que aquí cada unión, cada anuncio y cada mención se decide con los datos del análisis de cada canción.

Tres piezas, cada una con su oficio

La API decide qué suena. El servicio que programa la emisión toma la playlist al aire, revisa lo que ya salió y aplica las reglas: anuncios en las uniones más débiles, menciones donde no hay voz cantada, sin repetir ni saturar. Con eso arma la próxima pieza y la entrega con los datos del análisis: dónde entra, dónde sale, cuánto dura el fundido y en qué segundo va la mención. Toda la lógica que validamos en el prototipo vive aquí, en .NET.

La programación es una semana tipo que se arma en un tablero, con una columna por día y las franjas en tarjetas que se arrastran como las de las tareas. Cada franja dice qué playlists suenan, cada cuántas canciones entra un anuncio, si se dice la hora y si hay anuncios a una hora fija. Los cambios se preparan en un borrador sin tocar lo que suena, y al publicarlos quedan como una versión nueva que sale al aire en el siguiente corte entre canciones. Cualquier versión anterior se puede restaurar. Donde no hay franja, suena la programación de respaldo de la señal: sus playlists una detrás de otra. Los anuncios no se funden con la música, de forma tal que el tono de Breve que los abre y los cierra se oye completo.

Una emisora, dos señales

Desde el 11 de octubre, Radio Breve emite dos señales, como las grandes emisoras públicas que tienen varias cadenas con un mismo nombre, cada una con su propio estilo de programación. Sigue siendo una sola emisora y un solo motor, pero cada señal tiene su propia semana en el tablero, sus versiones, su cola y su registro, así que las estadísticas dicen qué sonó y quién escuchó en cada una. En la aplicación y en este sitio se pasa de una señal a otra sin que la música se detenga, y el reproductor recuerda la última que se eligió. Más adelante, cada señal podrá tener su propia marca.

A la hora exacta, el tono de Breve y la voz de Ramona dicen la hora encima de la música, que baja un momento y vuelve a subir sin que la canción se corte. La entonación cambia con el momento del día: con energía en la mañana, cálida en la tarde, tranquila al cierre de la jornada.

El motor ejecuta. El motor de emisión es Liquidsoap, un programa abierto hecho exactamente para automatizar radios por internet. Pide la pieza a la API un poco antes de que termine la canción, une una con otra en el punto exacto, baja la música mientras habla una voz, iguala el volumen de todo y emite sin detenerse. No decide nada, pues la inteligencia está en la API, y por eso el motor podría cambiarse algún día sin perderla.

La señal llega a todos. Sale en dos formatos a la vez, por la misma puerta, y el motor emite una sola vez para todos los que escuchan, sean diez o cien.

Lo que suena y quién escucha

Cada pieza que sale al aire queda anotada con la hora y los oyentes que tuvo, y cada persona que escucha deja su sesión: desde qué equipo y cuánto tiempo. Cruzando las dos cosas sabemos qué escuchó cada quien, cuántas veces sonó cada canción y en qué horas hay más gente. Ese mismo registro es el que permite que, si la API se reinicia, la emisión siga donde iba en vez de volver al principio. En la aplicación, el Reproductor acompaña: sigue sonando en una barra discreta mientras se trabaja en cualquier otra parte de Breve, muestra cuántos están escuchando y deja ver la cola de lo que viene, con la opción de saltar una pieza o darle prioridad.

Lo que estamos probando

Cada pieza de Radio Breve responde a una pregunta técnica que nos interesa resolver para toda la plataforma.

Primer hito de Carbon

Radio Breve es el primer módulo de la aplicación construido desde cero con Carbon Design System y nuestra Rejilla 2x, en la que todo se mide en múltiplos de 8 píxeles. No partimos de cero, sin embargo: usamos la misma base que ya sostiene a este sitio, con sus colores, su tipografía y las lecciones que dejó llevarla a producción. Empezamos por aquí porque es un módulo nuevo, sin pantallas heredadas que respetar, y porque un tropiezo en una emisora interna se corrige en una tarde.

Así validamos componentes, formularios, tablas, diálogos y modo oscuro en un caso real antes de tocar facturación, inventario o nómina. A fin de cuentas, cada componente que el equipo resuelva en Radio Breve queda listo para reutilizarse en la migración del resto de la plataforma.

Del wireframe a la pantalla

Antes de diseñar pantallas definimos la navegación: qué opciones tiene el módulo, cómo se pasa de una a otra y qué bloque ocupa cada cosa, en grises a propósito, porque en esa etapa el color y la tipografía distraen de lo que se está decidiendo, que es el recorrido. El módulo tiene cuatro opciones, Reproductor, Contenidos, Programación y Configuración, y tres de ellas ya están en uso con Carbon de verdad. Contenidos reúne la biblioteca de canciones, con su análisis y cuántas veces sonó cada una al aire; las playlists, mezcladas o de sueltas, que se ordenan arrastrando y muestran cuánto combina cada unión; y los anuncios, entre ellos las veinticuatro horas en punto, que se activan o se apagan una por una. Debajo de las pantallas actuales quedan los wireframes con los que empezamos, para comparar.

1. Reproductor

2. Contenidos

Tres pestañas, y en cada una se escucha y se agrega contenido.

3. Programación y 4. Configuración

La voz como interfaz de Breve

Breve se usa hoy desde la web, el celular y los reportes impresos, y queremos sumar una cuarta forma de usarlo: la voz. Pensamos en quien trabaja en primera línea, el operario de producción, el que despacha en el almacén o el que va en ruta, que no tiene una computadora delante ni puede mirar una pantalla mientras trabaja, pero necesita saber qué pasa en Breve y responderle. Radio Breve es el laboratorio natural para probarlo, porque ya resolvió lo difícil: una voz propia con la pronunciación correcta de la marca, el tono de Breve como firma sonora, un motor que dice algo encima de la música sin cortarla y un registro de qué sonó y quién lo escuchó.

La idea se apoya en cinco principios. Cada aviso se entiende completo la primera vez, en una frase corta que dice quién, qué y qué hacer. Se avisa lo útil y no todo, porque una voz que habla de más se deja de escuchar. Lo que se dice en voz alta lo oye cualquiera, así que los avisos para todos no llevan montos ni datos personales, y lo sensible va por un canal personal. Todo aviso abre con el tono de Breve, para reconocerlo sin pensar, y la urgencia se distingue por el sonido. Y quien recibe un aviso puede responderlo, con la voz o con un toque, y Breve confirma que entendió.

La primera pieza es la más sencilla y la que más rápido se nota: el dictado. Junto a cualquier campo de texto de Breve habrá un micrófono para hablar en vez de teclear, y lo dicho vuelve escrito y con puntuación para revisarlo antes de guardar. Sirve para la nota de una tarea o de un caso, la descripción de una incidencia, el comentario de un avance o el mensaje por altavoz, y funciona igual en la computadora que en el celular, sin instalar nada. La transcripción la hace el mismo servicio que ya convierte en texto las notas de voz que llegan por WhatsApp, entiende el acento dominicano y los nombres propios de cada empresa, y el audio no se guarda: solo queda el texto. Entender bien lo que alguien dijo es, además, la mitad del camino para conversar con Breve.

Como la señal de la emisora es una sola para todos, los avisos de una empresa no pueden viajar dentro de ella, porque los oirían las demás. Por eso se mezclan en el reproductor de cada persona: cuando llega un aviso para su empresa, su reproductor baja el volumen de la transmisión, suena el tono de Breve con el aviso y la música vuelve a subir, mientras el resto de las empresas sigue escuchando sin interrupción. Cada empresa decide si los avisos de voz suenan o no, cuáles (tareas asignadas, tareas por vencer, casos nuevos, avances de proyecto), si los textos dictados para el equipo se leen en voz alta, cuánto baja la música y en qué horario; cada persona puede silenciarlos en su propio reproductor, pero no encenderlos si su empresa los tiene apagados.

Los primeros avisos serán los que más cambian el día de un equipo: una tarea asignada, una tarea por vencer, el avance de un proyecto y la llegada de un caso. Para que no saturen tendrán tres niveles de prioridad, los urgentes en el momento, los normales en el siguiente corte entre canciones y los informativos agrupados en un resumen cada hora («tres tareas nuevas para producción»), dentro de la jornada de cada empresa y con un límite por hora. Mediremos si sirve con el tiempo que pasa desde que ocurre algo hasta que alguien actúa, cuántos avisos se escucharon de verdad y cuántas tareas se cerraron con la voz; el aviso que no cambie lo que la gente hace se apaga.

Lo que aprendimos

Un laboratorio vale tanto por lo que funciona como por lo que se tropieza en el camino, y estas son las lecciones que ya nos dejó Radio Breve, contadas para que le sirvan a cualquier proyecto del equipo. La primera es probar como se publica: la primera versión no llegó a producción en el primer intento, pues los estilos de Carbon pasaban un límite de tamaño que solo se aplica al compilar para producción y en las pruebas del día a día nunca se vio. Ahora se cargan aparte, solo al entrar al módulo, y antes de publicar se compila igual que en producción. La segunda es de forma, y es revisar el primer dato con acentos: un paso intermedio leyó unos archivos con otra codificación y guardó «Programación» con caracteres extraños. Se reparó en minutos, pero desde entonces, después de la primera carga con tildes y eñes, se mira cómo quedó antes de seguir.

Aprendimos también que un sistema de diseño nuevo puede convivir con el viejo, pues Carbon vive aislado dentro del módulo, de forma tal que el resto de Breve no cambió ni un píxel, y eso es lo que permite migrar por partes en vez de todo de una vez. Que cada canción se analiza una sola vez: si dos empresas suben la misma canción, se guarda y se analiza una vez aunque cada una la vea como suya, porque el análisis es lo costoso y toma minutos por canción. Y que hay que mirar lo que ve el contenedor, no lo que creemos que ve: el primer arranque del motor en la nube falló porque el script quedó una carpeta más adentro de donde lo buscaba (la herramienta con la que se subió y el contenedor ven el mismo disco desde raíces distintas), y se resolvió pidiéndole al propio contenedor que dijera qué veía. Desde entonces, ante un «no encuentro el archivo», lo primero es preguntarle a quien lo busca.

Las últimas tienen que ver con la forma de la emisión. Una sola pieza decide: al pasar de una playlist a toda la programación solo cambió la API, y el motor siguió igual porque no decide nada, lo que confirma la división de oficios que elegimos. Lo que se prepara por adelantado tiene que saber volver atrás: la emisión arma las próximas piezas con anticipación, y al publicar una programación nueva esas piezas se descartaban junto con el lugar donde iba cada playlist, de forma tal que una playlist de catorce canciones sonaba seis en bucle. Lo descubrimos mirando las estadísticas, no oyendo la radio, y ahora, al descartar, la emisión vuelve a la primera canción que todavía no sonó. En resumidas cuentas, también aprendimos que publicar seguido no tiene por qué molestar: en una sola madrugada salieron dos versiones de Radio Breve sin que nadie que estuviera usando Breve lo notara.

Preguntas frecuentes

Lo que no hace falta para entender Radio Breve, pero que suele preguntarse cuando se mira de cerca.

Un aviso se puede grabar desde la aplicación o mandar por WhatsApp, escrito o dictado, para que Ramona lo lea con el estilo de la emisora y quien lo envía no tenga que poner su voz. Lo oyen los usuarios de la empresa que lo envía que en ese momento tienen Breve abierto, en la computadora o en el celular, estén o no escuchando la emisora y en cualquier pantalla. A quien tiene la radio sonando, la música le baja, suena el tono de Breve, luego el aviso, y la música vuelve a subir. A quien tiene Breve abierto sin la radio, el aviso le suena solo, con su tono. No lo oyen quienes escuchan desde este sitio, desde una bocina inteligente o desde una aplicación de radio, porque esa señal es la común y no lleva los avisos de nadie. Tampoco las demás empresas, ni quien tiene Breve cerrado, porque los avisos suenan al momento y no se guardan para después.

Al enviar un aviso, Breve dice a cuántos equipos conectados llegó. Ese número cuenta pestañas y dispositivos abiertos, no personas, así que alguien con dos pestañas cuenta dos. Una pestaña recién abierta en la que todavía no se ha tocado nada puede quedarse callada, porque los navegadores no dejan sonar audio hasta la primera interacción con la página. Para que un aviso llegara también a quien escucha desde fuera de Breve tendría que viajar dentro de la señal común, como los anuncios, y entonces lo oirían todas las empresas. Por eso los avisos de cada empresa se quedan en el reproductor de su propia gente.

En dos a la vez y por la misma puerta. El HLS corta la señal en trozos de unos seis segundos, y es el que mantiene la música sonando en el celular con la pantalla apagada. El MP3 continuo es un solo flujo sin fin, como las radios por internet de siempre, y es el que usan hoy el Reproductor de Breve, las bocinas inteligentes, los equipos de sonido y las aplicaciones de radio.

Formato	Cómo funciona	Para quién
HLS	La señal se corta en trozos de unos seis segundos y una lista que se actualiza dice cuáles son los últimos.	Los celulares, que la mantienen sonando con la pantalla apagada. Es el formato al que pasará la aplicación.
MP3 continuo	Un solo flujo sin fin, como las radios por internet de siempre.	El Reproductor de Breve en esta primera versión, las bocinas inteligentes, los equipos de sonido y las aplicaciones de radio.

Era tentador meter el motor dentro de la API, que ya corre en producción. Lo descartamos por tres razones. La primera es que la API se publica varias veces al día y cada publicación reinicia su proceso: con el motor adentro, la radio se callaría con cada versión. La segunda es que la API puede repartirse en varias instancias, y si cada una emitiera habría varias radios distintas sonando a la vez. La tercera es que el motor no es .NET, y en un contenedor viaja con todo lo que necesita.

La decisión fue empezar en los servidores de producción que ya pagamos, como una aplicación más, siempre encendida y con una sola instancia. No suma costo de cómputo y una señal de audio usa poca CPU. Si se ve que le quita recursos a la API, el mismo contenedor se muda a Azure Container Apps sin tocar el motor.

Tampoco hizo falta construir una imagen propia. El motor corre con la imagen oficial de Liquidsoap, tal como la publican sus autores, y lo único nuestro es un script corto que se guarda junto al código de la API. Cambiar cómo suena la radio es cambiar ese script, no reconstruir un contenedor.

Con HLS, lo que se oye va entre diez y veinte segundos detrás de lo que emite el motor, y con el MP3 continuo unos pocos segundos. Para la música y los anuncios no importa, pero para un aviso urgente sí, así que mediremos alternativas de menor retraso.

El motor no se cae: termina lo que ya tenía preparado y queda en silencio hasta que la API vuelva. El siguiente paso es que en ese caso toque una lista de respaldo, para que la señal no se quede callada nunca.

No. El motor pide cada pieza con tiempo y la API se publica sin pausas, así que entre una versión y otra la música sigue sonando. Lo mismo vale para el propio motor, que se publica en un espacio de prueba y luego se intercambia con el que está al aire en unos segundos.

Por ahora sale directo del motor, que con los oyentes de hoy le sobra. Cuando la escuchen muchas más personas, la idea es repartir los trozos de HLS desde un almacenamiento en la nube pensado para eso, de forma tal que el motor emita una sola vez sin tener que atender a cada oyente.