SuperRack Performer: vocal latency and effects returns

Identify the signal path and software version before measuring

Identify where latency can accumulate and how the host can route the vocal and effects returns. Record the product name and build with the session file before testing a change.

Separate clocking, driver buffers and processing

The official Performer comparison places processing on the computer; SuperRack SoundGrid uses a server. A SoundGrid card can carry audio to a native host without a server processing its plugins. Connecting a server does not, by itself, change Performer's processing engine.

For QRec, the 20-page manual, pp. 6–7/10 distinguishes the Network Buffer, master device and displayed sample rate. Its Network Buffer defaults to 512 samples and may need to be increased if the network port is overloaded. This is separate from the host's ASIO/Core Audio buffer: record both where applicable.

The WSG-Y16 V1/V2 manual, p. 8, Features limits SoE to V2. Record the card, firmware, intended clock master and synchronization status before changing clock settings.

Suggested rehearsal check: start with the signal path and clocking agreed with the operator, with no plugins. If artifacts are already present, save the synchronization and load readings before trying another buffer setting. Change one setting in a copy outside the event and repeat the same material. If the result improves, record what changed; you still need to check whether the resulting latency is suitable for that destination.

Samples and milliseconds: the calculation and two different plugins

To convert samples to time, use t = 1000 × samples / sample rate in Hz. The table is a calculation based on a buffer of B samples in each direction at 48 kHz. It excludes additional buffers, conversion, transport, plugins and compensation. These are not measurements or recommended settings.

In the Waves comparison, the example gives 256 samples in each direction, 512 in total and approximately 5.3 ms. Those figures do not agree: 512 / 48,000 × 1000 gives 10.67 ms. Use the explicit calculation rather than treating the published time as a rehearsal result.

The official Plugin Latency table lists 3072 samples for Waves Tune in the Native/SoundGrid column at 44.1–48 kHz: calculated at 48 kHz, that is 64 ms. Tune Real-Time has a separate entry showing zero or near-zero latency, subject to the table's note. The shortened name “Tune” does not identify which component is loaded.

The Tune Real-Time manual, V16 update file, p. 5 explains that it reports zero latency to the host, but detection and correction can add 0 to 4 ms depending on the pitch. On p. 8, Speed controls the correction speed. It is neither a transport buffer nor a measurement of total latency. Record the component and settings, and compare a phrase containing low and high notes during rehearsal.

Compensation and Bypass: check what actually changes

The 134-page Performer manual, pp. 48/73/90 distinguishes three operations. Bypass keeps the plugin in the chain and retains its processing load; Disable removes it from processing and may reduce load and latency. Latency Compensation Off excludes the plugin's latency from the calculation but does not remove the delay itself.

To compare them, save a copy and record the initial state. During a rehearsal break, try one operation at a time and check the displayed value, listening result and dropouts. If only the displayed number falls, also record whether the voice still arrives late: these are different observations. Restore the initial state before the next pass.

In Performer, p. 48, Align all Racks Automatically uses the highest latency in the session; Align by Latency Groups aligns racks within each group. Check which racks share a group and destination. The manual warns of possible audio interruptions when changing the plugin structure (p. 57).

Do not turn compensation off as a general fix. If paths are combined at a destination, listen to them separately and then together at the same reference level to check the effect of the change. Record any alignment that still needs to be validated.

Processed vocals and effects: map the return paths

Treat this as a routing option to test, not a confirmed result or a way to use only one tuning instance. First identify the exact component: Waves Tune or Tune Real-Time.

The Performer manual, pp. 87/74 describes rack inputs from device channels and External Inserts with physical sends and returns. That procedure does not document an internal bus that sums racks.

Reserve two clearly named returns and two test racks. Compare the vocal without delay or reverb against the effects return separately, then test the intended sum. Decide whether the effects return should include dry vocal or effects only, so an unintended second copy of the vocal is not added.

In the session copy, compare both tuning instances and their settings before rehearsal, and check them again after cue changes. Watch host load with both active. If the design sends a console return back to the host, draw and measure that extra trip: do not describe it as internal routing.

Another option is to apply console effects to the tuned return, if the exact console model supports the required patch and pickoff point. Check that path in the console manual and session before using it; there is no single routing recipe here for CL/QL or WING.

Record latency, dropouts and listening observations through to the destination

Complete the latency and returns worksheet. Define the endpoints and method before recording milliseconds. A reference and return recorded simultaneously can help compare paths; identify and calibrate the measurement system before presenting the value as absolute latency. For a tuning plugin, also choose suitable vocal material: a single note does not cover its behavior.

Suggested rehearsal passes: first with no plugins, then with tuning, then with the full chain. Keep the sample rate, buffer and measurement points unchanged. Record duration, load, dropouts and listening observations for each pass. Compare another buffer or group in a separate pass. A short passage without dropouts does not validate the full show duration.

For IEM, agree on the test path with the operator and singer. If the measurement stops before the monitoring system, state that limit. Record the singer's listening observations separately from the measured value; this guide does not set a universal latency threshold.

Common mistakes include treating samples as milliseconds, confusing Speed with the buffer setting, and applying one plugin's figure to the whole chain. Keep the session revision the next operator should load, along with a list of tests still to run.

Related: WING and SuperRack connections (Spanish guide), Routing and snapshots and Dante clocking and dropouts. Include the rehearsal checks when preparing the event audio system.