Bug Report for JUCE: VST3 elapsed time

[JohnRStone2011]

The issue described here seems to be the result of a bug in JUCE:

"audio plugin demo" as VST3: elapsed-time display is confusing me

I’m seeing something I can’t account for. I’ve created a new Projucer project, targeting both VST2 and VST3, and I’ve copied the .cpp and .h files over to it from “audio plugin demo”, since that’s a good start for what I want to do. It compiles fine in Visual Studio 2017, and I can load and play both the VST2 and VST3 version in Reaper 5. But the elapsed-time field in the VST3 version is showing a very large value, and the value is continuously increasing, even when Playback is stopped, and the…

[JohnRStone2011]

I find that JUCE/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp contains

info.timeInSeconds = ti->samplePosition / ti->sampleRate;

whereas JUCE/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp contains

info.timeInSeconds = processContext.systemTime / 1000000000.0;

I’m not sure whether this code from these files is what’s being used in my project, but it seems likely, and it would account for the different results between the VST and VST3 versions of my project.

[fr810]

OK. This is now fixed on develop with commit 665b0a3.

[yfede]

Is this worth a mention in the breaking changes?

[fr810]

Yeah I was thinking about that but I can’t see how people may have relied on the old behaviour. The systemTime is pretty much meaning less as an absolute value. And if people were using the relative value then the new code should work well during playback anyway. But yes, even when taken as a relative value, it won’t monotonically grow (as the old value would) as it will jump when the transport jumps.