How to optimize Scriptnode Networks?

[HISEnberg]

A general inquiry on how best to optimize a Scriptnode network. Perhaps a more seasoned user can answer some of these questions. My hope is this could lead into a discussion around "Scriptnode: Best Practices" but my primary focus is on latency here.

• What is the default block size in Scriptnode if I do not wrap my network in a container_fix_block or other container type (frame, oversampling)? My gut feeling is it is processed in chunks of 32 or 64 samples. Does anyone know where in the HISE source code this is set?

• How to measure the latency introduced by my Scriptnode network? I imagine driving an impulse through the plugin and recording the output should reveal this (for a DAW specific context). Is this something Plugin Doctor can measure, or does someone have a better methodology?

• How to compensate for latency introduced by the Scriptnode network? I see in the API Engine.setLatencySamples, but it is unclear to me what it does. Are we meant to measure the latency of the scriptnode network (for example 32 samples) and this function will broadcast to the host the latency introduced by the plugin (i.e. "this plugin introduces 32 samples of latency, so compensate for that")? What does the host actually do with this information?

• Dynamic block size. If I want the user to be able to set a dynamic blocksize (using the dynamic_blocksize container, I imagine I want to dynamically set the Engine.setLatencySamples as well.

[aaronventure]

@HISEnberg said in How to optimize Scriptnode Networks?:

What is the default block size in Scriptnode if I do not wrap my network in a container_fix_block or other container type (frame, oversampling)? My gut feeling is it is processed in chunks of 32 or 64 samples. Does anyone know where in the HISE source code this is set?

It's whatever the blocksize of the end user's interface is. This is why it's paramount that you set block size within the network for any network where you have continuous processing. An example of processing that doesn't require you to set block size is minimum phase filtering (which covers all HISE filters).

Faust will always use frame processing even if you drop it into a fix block node. In the future, once the ondemand primitive comes to Faust, we'll be able to introduce block processing and have smaller block sizes for Faust.

@HISEnberg said in How to optimize Scriptnode Networks?:

How to measure the latency introduced by my Scriptnode network? I imagine driving an impulse through the plugin and recording the output should reveal this (for a DAW specific context). Is this something Plugin Doctor can measure, or does someone have a better methodology?

You should know what latency you're introducing. The only node that will introduce any latency is the delay node. You'll only be able to introduce latency using custom processing in Faust or SNEX, at which point you'll know exactly what the values are and will be able to call Engine.setLatencySamples() to report PDC to the DAW. In Faust you'll most likely work with samples so you have the value or the formula already. If you're working with milliseconds, you're calling Engine.setLatencySamples(Engine.getSampleRate()/1000 * latencyMs) where latencyMs is the latency that you know you're introducing.

@HISEnberg said in How to optimize Scriptnode Networks?:

Dynamic block size. If I want the user to be able to set a dynamic blocksize (using the dynamic_blocksize container, I imagine I want to dynamically set the Engine.setLatencySamples as well.

I think only if you're exceeding the interface buffer size, but you'll have to test that.

[HISEnberg]

@aaronventure Thanks for the feedback it is appreciated!

I ran a test with a sidechain saturator/compressor I am working on. It is not wrapped in any fix or frame block. I noticed a 32 sample delay at the output. I think other nodes might introduce latency other than just delay nodes (perhaps the limiter and the send and receive nodes)

[ustk]

@aaronventure said in How to optimize Scriptnode Networks?:

The only node that will introduce any latency is the delay node

The oversampling does introduce latency too

[aaronventure]

Hah I stand corrected, thanks.

[orange]

@HISEnberg said in How to optimize Scriptnode Networks?:

• How to measure the latency introduced by my Scriptnode network? I imagine driving an impulse through the plugin and recording the output should reveal this (for a DAW specific context). Is this something Plugin Doctor can measure, or does someone have a better methodology?

You can do a Null test in your DAW for this.

• One channel will be the dry (unprocessed) signal.
• The other channel will be the processed signal, that is, the channel where the plugin is.

Make one channel phase invert. If these two channels are identical, the overall result will be silence. Since there is a delay at the sample level in the channel where the plugin is, determine the amount of sample delay required until the result of the combination of these two channels is silence with a sample delay in the dry channel.

The amount of delay you will apply to silence the sound in the dry channel is the amount of delay created by your plugin's DSP.

• How to compensate for latency introduced by the Scriptnode network? I see in the API Engine.setLatencySamples, but it is unclear to me what it does. Are we meant to measure the latency of the scriptnode network (for example 32 samples) and this function will broadcast to the host the latency introduced by the plugin (i.e. "this plugin introduces 32 samples of latency, so compensate for that")? What does the host actually do with this information?

If your plugin has a delay of 32 samples, the DAW will play your plugin 32 samples ahead, thus compensating for the delay. Therefore, it is necessary to inform the DAW of this delay value with Engine.setLatencySamples.