HISE FX and delay compensation

[Fortune]

@Christoph-Hart I used that in a simple Param Eq plugin (10 nodes). The plugin has a great latency (about 500 samples), I measured it with an audio editor. But when I declare the latency with Engine.setLatencySamples() on init, it doesn't work on Ableton Live 10, Cubase 10, Studio One in Mac and PC :/ So if that doesn't work, there is an optimization should be done in Hise. Because a simple eq plugin shouldn't cause phase cancellation. It is a very BAD BAD issue.

[Dan Korneff]

I just downloaded scriptnode to test today.
General Question, wouldn't the latency change with sample rate? So we'd have to make a case for each?

[Fortune]

@dustbro
For plugins wishing to report their latency to be factored into the Plugin Delay Compensation of the host, or hosts which need the plugin latency to do their own adjustments. Juce provides a pair of functions for getting/setting the current plugin latency. To report the amount of delay applied by your plugin, simply call "setLatencySamples" from your plugin processor. I think @Christoph-Hart added that feature to Hise.

Yeah you need to measure the delay time amount (not in Milliseconds, just samples) for each plugin. I did it with a very short sine wave. I just put my plugin to sine wave channel, and export it. Also exported without plugin. So the difference between plugin and dry audio will be our delay amount. Very very short but very big problem.

[Dan Korneff]

@Fortune said in HISE FX and delay compensation:

Juce provides a pair of functions for getting/setting the current plugin latency.

I see Engine.setLatencySamples()
What's the other part of the pair?

[Dan Korneff]

@Christoph-Hart I can't seem to compile your latest scriptnode as of 2 hours ago

1>c:\program files\hise-scriptnode\stk_wrapper\stk\src\adsr.cpp(16): fatal error C1083: Cannot open include file: 'ADSR.h': No such file or directory (compiling source file ..\..\JuceLibraryCode\include_stk_wrapper.cpp)

[d.healey]

@dustbro Notice the red X

[Dan Korneff]

@d-healey Where can I see this on the GitHub, and what does that mean?

[d.healey]

@dustbro When Christoph "commits" an update to GitHub it is added to a timeline of all previous commits for that branch. You can view it by clicking on "commits" after you have selected a branch.

Christoph has setup the Git repo so that each time a new commit is added the code is automatically tested, if it fails the test a red X is placed next to the commit. If you see a red X then you will probably get problems if you build from that commit and you should choose an earlier or later point in the commit history to get the code from.

[Fortune]

@dustbro For example, if the delay time of the plugin is 500 samples; just insert this code into the begining of the on init script;

Engine.setLatencySamples(500);

With this way, plugin reports delay compensation to the DAW in the very begining of the initialization.

I am using it on fx plugins it doesn't give errors. But it doesn't work in almost all DAWs.

[orange]

@dustbro @Fortune Yeah I see that issue too.

Hise reports the latency to the daw successfully, but somehow compensation doesn't work (except Reaper). However Since Reaper has a great built in auto compensation, if you enter setLatencySamples, the sound starts ahead; because it compensated double :)

[ustk]

@orange @Fortune Which means we have to handle every DAW case differently...?

[Christoph Hart]

The idea of this entire call is to report to the host how many samples it needs to compensate (= preroll). It‘s a basic feature in JUCE which I‘ve just wrote a simple wrapper for it. Apparently it doesn‘t work for the majority of hosts but there‘s nothing else I can do.

Now I don‘t have the time currently to go through every host and check whether it works, but we can make a list here with hosts that support / don‘t support this feature, then I can take it to the JUCE team.

[Christoph Hart]

Also if anyone finds a useful information in the JUCE forum (just search for setLatencySamples), you‘ll get plenty of topics), I am happy to take that into account.

[Dan Korneff]

@Christoph-Hart I'll take a look on the forms this weekend.

[orange]

I found this threads, they may be helpful. Also I see that they prefer to use setLatencySamples() in prepareToPlay. But we're using it in onInit, could that be the cause?

https://forum.juce.com/t/cubase-latency-issues/27669

https://forum.juce.com/t/look-ahead-vs-daws-latency-compensation/30384/2

https://forum.juce.com/t/vstplugininstance-getlatencysamples/7934

https://forum.juce.com/t/setlatencysamples-int-newlatency-in-cubase-and-bitwig-in-vst3-win-and-mac/15061/3

[Christoph Hart]

Well, onInit comes way before prepareToPlay, so if it's not set correctly by then, we're screwed anyway.

However, I've encorporated a few things mentioned in the threads:

• resend the latency update in prepareToPlay if it's different than at the last call
• add a static delay line to the bypassed processing chain (I thought the host would do this, but it makes sense that it's the plugins job to delay it).

While the first one is pretty cosmetic, I think the last one might be actually helpful.
Unfortunately I am not in my studio right now, so I can't test the hosts, but I pushed it to the scriptnode branch so if anyone wants to check if this improves the situation, have a go.

[orange]

@Christoph-Hart I've just tried, result is the same :/

[Dan Korneff]

@orange @Christoph-Hart I just tested latest version of ScriptNode. Cubase is picking up the reported latency.
Gotta test to see how accurate it is.

[Fortune]

@dustbro Yeah Cubase can detect the latency value, there is no problem about it. You can also see that in the Cubase plugin manager.

But the problem is, wet and dry channels are not in sync. Delay still persists.

[Dan Korneff]

@Fortune got it.