Issue with Latency Reporting (EDIT: now fixed)


#1

On Cubase, we've noticed that our latency is not being reported correctly. Latency is only updated when our plug-ins are enabled and disabled. In Cubase/Nuendo, latency should be updated on start/stop (i.e. prepareToPlay).

 

I found this line in juce_VSTPluginFormat, prepareToPlay:

setLatencySamples (effect->initialDelay);

 

In juce_VST_wrapper, we have:

setInitialDelay (filter->getLatencySamples());

in audioProcessorChanged, resume, and constructor. Is initialDelay being reported correctly for it to be updated for all start/stop events?

 

http://www.steinberg.net/forums/viewtopic.php?f=186&t=69320
 


#2

I think you misinterpreted arnes posts. If a plugin changes the latency while playing, the PDC will be working correctly after cubase stops and starts again (There is no need to report the changed latency again). btw its the same in logic (I verified). 

In my experience cubase works correct, do you have a steps by step instructions, to reproduce the issue?

(BTW juce_VSTPluginFormat is only for plugin-hosting)

 


#3

Our tester reports that VST2 works fine in Cubase. It's actually VST3 that's the problem.

Regarding Arne's post, PDC for our plug-in is not working correctly after start-stop. It only updates after disabling and re-enabling our plug-in.

 

I found this similar issue: http://www.juce.com/forum/topic/setlatencysamplesint-newlatency-cubase-and-bitwig-vst3-win-and-mac

However, the steps to resolve that did not fix our plug-in.


#4

User experience minefield.

That was my experience when I tried reporting different latency with different settings.  :) 


#5

My colleague seems to have found a fix. In juce_VST3_Wrapper:

 


void audioProcessorChanged (AudioProcessor*) override
    {
        if (componentHandler != nullptr)
            componentHandler->restartComponent (Vst::kLatencyChanged & Vst::kParamValuesChanged);
    }
 

Change it to "Vst::kLatencyChanged | Vst::kParamValuesChanged". That fixes the problem for us, although we haven't done extensive testing to see if that breaks anything else.


#6

Right, it seems like we want to send both flags for latency changing and a parameter changing, so that should be a bitwise OR, not AND. Unless I'm misunderstanding. 

Just to go over the situation again, we're calling setLatencySamples() inside of processBlock and processBlockBypassed. We have a knob which sets the variable delay in real-time. Using VST2 in Cubase and other DAWs, latency compensation works correctly as we adjust this knob during playback, but when using VST3 the latency is only updated after turning bypass on/off.

When we change this code to use a bitwise OR instead of an AND, the VST3 seems to behave just like the VST2 (latency is updated in real-time). 

Thanks. 


#7

Are you testing with AAX and Audio Units as well? 


#8
​Change it to "Vst::kLatencyChanged | Vst::kParamValuesChanged". That fixes the problem for us, although we

Looks like typo, a clear bug! Juce team wake up!

 

 


#9

Goldarnit, that certainly does look like a classic typo! Fixed now, thanks!


#10

Ouch! That one's probably my fault!