Handling Latency for Delay-Based Modulation Effects

[Yinxi]

Hi,

I recently tried to build a small vibrato effect in Scriptnode, and I’m trying to better understand how latency should be handled.

I want to understand the correct way to think about latency for delay-based modulation effects.

My first question : Does the latency calculation tool correctly handle delay processing, for example with nodes like "jsDelay", or can it be “tricked” by this kind of processing?

Another question: if the latency is not fixed (for example, in a vibrato where it changes depending on the rate and depth values), how can we handle latency when it is constantly varying?

I have seen earlier on the forum that latency can be set through the range of a knob, but if latency depends on multiple parameters, how should this be handled?

PS: I used ChatGPT to help me write this question to make sure it is clear.

[HISEnberg]

@Yinxi Good question.

Just to start, latency refers to a short period of delay (usually measured in Samples in DSP) when an input signal enters the plugin and when it exits the plugin. In many cases that is not desirable so HISE (using the JUCE backend) has a function called Engine.setLatnecySamples. This works by telling the host/DAW: "Hey, this plugin introduces X samples of latency, so adjust the signal so it is X samples further ahead in time".

An example of this happening in Scriptnode is if you use oversampling, which will generally introduce a few samples of latency. So you need to calculate the amount of latency introduced (Use Tools>Check latency of signal chain) and use Engine.setLatencySamples to adjust it. This function is dynamic, meaning you can adjust the number of samples depending on the latency you are introducing. Example: if you have a knob that adjusts the oversample size from 2x to 4x, this might cause your latency to jump from 1 samples to 2 samples. You can write an if statement to change this and the host will be updated:

// pseudo-code
if (OversampleKnob = 2x)
   Engine.setLatencySamples(1);
else if (OversampleKnob = 4x)
   Engine.setLatencySamples(2);

Small note: Each host has a different way of handling the information it receives from a plugin so results may vary here. You need to make sure to update the latency report once when initializing the plugin, and any time after if changes(this is probably updated once per block).

But returning to your earlier question about vibrato, if you consider that latency is just a delayed signal, that is not necessarily a bad thing. Vibrato is basically just a time-varying delay (delay line modulated by an LFO). The pitch shifting comes from the rate of change of the delay. In other words, the delay(or latency) introduced by the Vibrato is precisely what you want, so there is no reason to adjust for the latency.

This is all an oversimplification but hopefully clarifies things a bit. You can test this out in a DAW to confirm as well. Run an impulse through your plugin and record the output and see how they line up.