Resumen

  • Una orden de inicio perdida puede dejar un hueco breve; una orden de finalización perdida puede mantener una nota o un ajuste incorrecto durante mucho más tiempo. Contar paquetes no distingue esos efectos.
  • El diario permite que el receptor emita correcciones a partir de un historial limitado. No retransmite cada paquete ni exige reproducir todas las notas que ya llegaron tarde.
  • Las pausas, los participantes nuevos, la cobertura del historial y las decisiones de reproducción condicionan la recuperación. Las reglas compartidas definen responsabilidades, pero no un único algoritmo para todos los instrumentos.

La mano se aparta, el estado permanece

El intérprete termina una nota. Su equipo envía la orden correspondiente, pero el paquete no llega al otro extremo. Allí, el instrumento sigue trabajando con la información anterior. No necesita recibir más mensajes para prolongar una decisión que ya había tomado.

El resultado concreto depende del sonido, de su envolvente, del pedal y de las órdenes posteriores. No toda pérdida de NoteOff produce un tono infinito. La dificultad de diseño es que puede hacerlo: el receptor no puede confiar en que algún acontecimiento futuro corrija por casualidad el estado que le falta actualizar.

En noviembre de 2006, el RFC 4695 puso nombre a esta diferencia. Separó los defectos transitorios de los indefinidos. La pérdida de NoteOn puede omitir una nota, pero esa ausencia normalmente no dura más que la nota prevista. La pérdida de NoteOff puede dejarla sonando. Y perder una orden de volumen de canal puede alterar todas las notas posteriores, aunque sus propios paquetes lleguen bien.

Es un ejemplo de funcionamiento, no una crónica de un concierto fallido. Su importancia está en que una red aparentemente recuperada puede alimentar un instrumento todavía equivocado. El final de la interrupción no equivale al final de sus consecuencias.

No se estaban transportando fragmentos de una grabación

MIDI representa acciones sobre instrumentos mediante órdenes simbólicas. El receptor genera el sonido a partir de esas órdenes y del estado que conserva. El formato descrito por estos documentos cubre las órdenes legales de MIDI 1.0 sobre su interfaz DIN; no convierte el diario en un mecanismo para reconstruir muestras de audio perdidas.

Esta dependencia del estado cambia el significado de recuperar. Si faltara una porción de una grabación, podría interesar reconstruir esa porción. Si falta una modificación de volumen, interesa que el instrumento deje de aplicar un valor antiguo a todo lo que viene después. La historia relevante no coincide necesariamente con una copia íntegra de la transmisión.

RTP ya aportaba herramientas comunes. El RFC 3550, de julio de 2003, define secuencias, marcas temporales y observación de la recepción, pero no garantiza entrega, puntualidad ni orden. Una secuencia permite detectar un hueco. No permite saber, por sí sola, si ese hueco dejó un sonido atascado.

La carga MIDI incorpora ese conocimiento de la aplicación. El RFC 6295, que sustituyó al documento de 2006 en junio de 2011, mantiene una obligación central: evitar que la interpretación musical renderizada a partir de un flujo sobre transporte no fiable conserve defectos indefinidos. Es una promesa deliberadamente distinta de eliminar todo fallo perceptible.

Corregir el presente con una versión suficiente del pasado

En un flujo que utiliza el diario de recuperación, cada carga lleva información histórica. El receptor que detecta una pérdida contrasta lo que sabe con el diario del paquete que termina ese episodio de pérdida. A partir de las diferencias puede emitir órdenes MIDI correctoras.

La operación no requiere retransmitir todos los paquetes desaparecidos. Su finalidad es convertir un error que podría seguir activo en una perturbación acotada. Una orden de parada generada localmente puede resolver el efecto de una orden remota ausente, aunque no borre los segundos de sonido incorrecto ya escuchados.

El historial tiene un comienzo explícito, el punto de control. Para el paquete actual I y un punto C, la cobertura va de C a I−1; las órdenes nuevas de I quedan fuera de ese pasado. Si C coincide con I, el historial correspondiente está vacío. Esta separación evita tratar las órdenes presentes y la información de reparación como si fueran la misma cosa.

También limita la garantía. La capacidad de recuperarse de cualquier número de paquetes perdidos se refiere a los paquetes dentro del historial cubierto. No hace recuperable una interrupción arbitrariamente larga. El receptor dispone del punto de control para comprobar si el diario alcanza el principio del hueco observado.

Saber que hubo una nota no obliga a tocarla ahora

El capítulo N del diario trata los patrones habituales de alternancia entre inicio y fin para una misma altura. Resume información útil para corregir el estado; no conserva todas las pulsaciones de toda la sesión. Los patrones más complejos, con inicios superpuestos, requieren apoyo adicional del capítulo E.

En particular, un registro NoteOn del capítulo N no lleva la hora exacta de ejecución de la orden original. Su bit Y recomienda reproducir o saltar la nota. La recomendación reconoce que llegar a conocer una acción tarde no la convierte automáticamente en una acción musicalmente útil ahora.

El RFC 4696, guía de implementación publicada en noviembre de 2006, describe un receptor que puede omitir un inicio atrasado y actualizar, aun así, sus registros de recuperación como si se hubiera procesado. No pretende engañar al oyente: simplemente mantiene coherencia para interpretar las siguientes órdenes sin añadir un ataque fuera de lugar.

El ejemplo tampoco identifica todos los patrones posibles. Una secuencia rápida de fin e inicio con la misma velocidad puede escapar a algunas pruebas y dejar que continúe el primer sonido hasta una parada posterior. El documento explica esa limitación. Convertir su algoritmo en una reconstrucción exacta de cada gesto sería atribuirle justamente lo que no promete.

La pausa que impide descubrir la pérdida

La misma guía plantea una situación sencilla: se pierde el paquete con NoteOff y el músico no vuelve a actuar durante cinco segundos. Si no se envía otro paquete RTP, el receptor puede tardar hasta el siguiente gesto en ver el salto de secuencia. El silencio del emisor prolonga el problema sonoro del receptor.

Los paquetes de guarda pueden llevar una lista MIDI vacía. No inventan notas para mantener ocupado al músico; ofrecen una nueva observación de secuencia y un diario que puede servir para reparar. Conviene distinguir una lista de órdenes vacía de un diario vacío, y ambos de un flujo configurado para no utilizar diario.

La guía propone ejemplos de intervalos cortos al comenzar la pausa y más largos si la inactividad continúa. Son opciones de diseño, no valores que todos los equipos deban adoptar. En la especificación de 2011, guardtime expresa una separación máxima entre paquetes consecutivos en unidades del reloj RTP. Incluso el rango que se describe como habitual se declara expresamente no normativo.

Además, los requisitos de control de congestión tienen prioridad sobre esa frecuencia solicitada. El RFC 3551 explica la obligación de coexistir razonablemente con otros flujos. Una aplicación no obtiene capacidad ilimitada por el hecho de que sus errores sean audibles. Enviar más oportunidades de recuperación puede ser útil, pero deja de ser una mejora si agrava la congestión que origina nuevas pérdidas.

Las órdenes antiguas pueden estropear una corrección nueva

Una llegada fuera de orden no es siempre una pieza bienvenida. El receptor puede haber corregido ya el estado gracias al diario de un paquete posterior. Si ejecuta después la orden antigua, corre el riesgo de duplicar una acción de reparación. El receptor NMP descrito en la guía opta por descartar esos paquetes.

Eso no convierte el descarte en el único algoritmo permitido. RFC 4696 es informativo y no normativo. Su ejemplo se diseñó para unas características de red concretas, trabaja con un subconjunto de órdenes y no usa un búfer de reproducción. El propio texto advierte que esa última decisión no satisface por completo una pauta de interoperabilidad que exige disponer de esa capacidad.

La norma exige que el tratamiento de paquetes fuera de orden no introduzca defectos indefinidos. Un receptor con búfer puede esperar al momento de reproducción para realizar la recuperación, porque el paquete considerado perdido quizá solo llegue tarde y todavía sea utilizable. El requisito común y la técnica elegida no deben confundirse.

Tampoco basta con imaginar que NoteOff siempre apaga de inmediato cualquier sonido. El pedal de sostenimiento y el orden de sus cambios importan. El diario puede no conservar todo ese orden relativo. Si el receptor no puede deducirlo de su propio historial, la especificación favorece evitar notas sostenidas erróneamente, incluso a costa de una alteración breve. La reparación admite una pérdida de fidelidad cuando ya falta la información necesaria para evitarla.

Recibir lo nuevo no asegura conocer lo antiguo

La política de envío predeterminada es de bucle cerrado. El emisor utiliza informes de los receptores, normalmente el número de secuencia ampliado más alto comunicado mediante RTCP, para reducir el historial que debe seguir enviando. Otro mecanismo de retorno acordado puede cumplir esa función.

Reducir el pasado ahorra espacio, pero obliga a cuidar a quien entra después. Un ajuste de volumen enviado al principio puede haber dejado de figurar en los diarios. Los receptores antiguos lo conocen; el nuevo recibe paquetes recientes sin saber ese valor. La especificación exige que el emisor, cuando advierte la presencia del nuevo receptor, asegure un inicio sin esos defectos persistentes.

Hay límites cuando el emisor todavía ignora que alguien escucha, como puede ocurrir en ciertos entornos de difusión. El receptor puede tomar precauciones ante notas atascadas, pero no adivinar un volumen que nunca recibió. La cobertura de la recuperación depende de hechos operativos, no de que una conexión parezca activa.

En 2017, el RFC 8088 destacó el estado resumido y la reducción del diario mediante RTCP como rasgos interesantes de RTP MIDI, especialmente para medios simbólicos muy dependientes del estado. Era una observación de diseño, no una evaluación de la cuota de mercado ni de la calidad de actuaciones reales.

Una denominación compartida no certifica la música

El registro audio/rtp-midi de IANA da a las implementaciones un nombre, parámetros y referencias comunes. Documenta un formato para transmitir MIDI en tiempo real. No demuestra cuántos equipos lo utilizan ni cómo se comportan en una red particular.

La revisión de 2011 corrigió figuras y detalles de sintaxis y configuración. Sus observaciones sobre la ausencia de problemas de interoperabilidad conocidos se refieren a esas correcciones, no a la perfección universal del sistema. Del mismo modo, los comentarios de entonces sobre aplicaciones que aún no eran habituales pertenecen a 2011, no al presente.

La contribución duradera de este diseño es una definición exigente, pero limitada, de la reparación. No es necesario fingir que nada se perdió para impedir que la pérdida siga actuando. Un buen receptor puede dejar sin tocar una nota tardía y, al mismo tiempo, negarse a dejar otra sonando sin final.