The issue described here seems to be the result of a bug in JUCE:
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.
OK. This is now fixed on develop with commit 665b0a3.
Is this worth a mention in the breaking changes?
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.