SuperRack SoundGrid e InTrigger: crujidos y golpes de batería que no disparan

InTrigger: separar detección, reproducción y ruta de batería

Reproduce crujidos con un virtual soundcheck en bucle. Bajar la entrada evita algunos crujidos pero limita las capas fuertes; reducir capas mejora ciertas combinaciones, sin el mismo resultado para todas. Al final retira los triggers de toms. No confirma la causa ni un ensayo final que repare el conjunto.

La carga y las pérdidas que cita pertenecen a ese montaje; no son mediciones nuestras.

Carga por núcleo y errores: guardar el estado antes de tocar el buffer

Waves, Common Questions, DSP performance meters, explica que cada rack se procesa en un núcleo. La media global y el pico no describen la misma cosa; buffer, recarga y frecuencia pueden redistribuir la carga. Registrá el pasaje y la configuración de cada captura para poder compararlas.

El manual SoundGrid de 156 páginas, pp.58–60, muestra media y pico por núcleo y Routing View para conexiones. En p.37 distingue sobrecarga de procesamiento de uso elevado de red: aumentar Server Network Buffer puede aportar estabilidad a costa de demora. No es una reparación confirmada del caso.

Ensayo propuesto: con la misma pista y los mismos puntos de escucha, guardá una captura antes del pasaje, otra durante el crujido y otra al terminar. Anotá fuente/destino del contador y cuánto duró la pasada. Si limpiás contadores, hacelo después de conservar el estado inicial; dos cifras de períodos distintos no sirven como comparación directa.

Primero repetí el patrón sin cambiar la sesión. Después compará una copia con menos capas o menos procesamiento y, en otra pasada, un único cambio de buffer. Registrá también golpes omitidos y demora del retorno. Si una condición deja de producir el crujido, conservá el archivo y el resultado; todavía falta comprobar el resto del repertorio.

Para separar procesamiento de reserva, el manual SoundGrid, p.56, permite asignar racks a grupos de servidores y ofrece Test Redundancy. Waves, Server Redundancy, recomienda pares del mismo modelo y advierte de un mute al conmutar; el manual usa “seamlessly”. No damos por probado un cambio inaudible. El Quick Start de servidores, p.4, describe las dos fuentes del Titan-R: esa reserva de alimentación es distinta de otro servidor que sustituye el DSP.

Si se propone otro servidor activo para los triggers, dibujá qué racks pasa a procesar y qué reserva tendrá cada grupo. No reasignes un servidor de backup contando con que seguirá cumpliendo ambos papeles. Dejá el ensayo de conmutación para una pausa acordada y registrá la escucha del destino.

InTrigger y Live: elegir controles que existen en ese componente

El manual InTrigger, 49 páginas sin revisión indicada, pp.4/14/49, describe Learn y Detection Graph en el componente habitual. Live usa Threshold y cuatro capas; no incluye esas funciones ni edición individual. Confirmá el componente cargado.

Guardá una captura y el build real del plugin para resolver esa diferencia antes del ensayo. La tabla resume el alcance del manual. Identificá los componentes de tu Quantum7 antes de aplicar el recorrido.

La página comercial llama a Live “zero latency”. El manual, p.49, distingue Plugin Latency de 0 ms y Detection Latency de 1,5 ms. Son datos del plugin; medí aparte el recorrido hasta monitores.

Golpe omitido o muestra inesperada: seguir entrada, detección y capa

En InTrigger habitual, pp.9/14–16, un golpe fuera de Target Scope no dispara aunque supere Threshold. Retrigger fija el intervalo mínimo; cambiar Focus, Separation o activar filtros reinicia la detección. Son comprobaciones distintas de simplemente subir la entrada. Para Live, seguí los límites del apartado anterior.

Proponemos elegir un pasaje con golpes suaves, fuertes y cercanos, más otro con bleed. Señalá los golpes esperados en una referencia y repetí sin cambios. Registrá si entra señal, si hay detección y si la capa produce salida. Si hay detección pero falta muestra, conservá ese dato; no lo describas como un golpe que el detector nunca vio.

En otra copia, cambiá sólo el control que corresponde al tramo investigado. Si esa operación reinicia la detección en el componente habitual, dejá tocar el material antes de comparar la nueva selección. Anotá el instante del cambio y el material usado; repetir Learn sobre fragmentos distintos puede dejar dos configuraciones que no estás comparando en igualdad de condiciones.

Para revisar capas, empezá por una sola en la copia. Después probá el modo de reproducción y la combinación previstas, anotando qué capa se esperaba en cada golpe. No bajes toda la entrada hasta perder la dinámica sin registrar qué parte dejó de funcionar. Conservá señal original y retorno en el ensayo, escuchados por separado antes de la suma.

Proponemos guardar una revisión con el pasaje de referencia, cerrar y reabrir esa copia fuera del evento y comparar los mismos golpes. Si difiere, guardá ambos estados para soporte, sin atribuirle todavía una causa.

Ficha de ensayo y entrega para batería, FOH y monitores

Completá la ficha InTrigger–SoundGrid con componente, builds, muestras, capas, rack, grupo y servidor. Los resultados quedan vacíos hasta ejecutar.

Antes de ensayar, acordá quién observa entrada/detección y quién registra carga/retorno. Si trabajan FOH y monitores, anotá el destino de cada comparación. Un cambio que evita crujidos pero omite golpes o demora el retorno requiere otra decisión; conservá ambas observaciones.

Errores habituales: buscar Learn en Live, usar la media global como único control de carga, sumar contadores de sesiones diferentes o contar una fuente redundante como un segundo procesador. La ficha ayuda a entregar el síntoma reproducible y el estado que debe recuperar el siguiente operador.

Relacionado: latencia de voz y retornos de Performer, sesiones DiGiCo–SuperRack y continuidad del show. Acordá el ensayo y la ruta de reserva con el operador del sistema de audio del evento.