projectTimeSamples in VST3 wrapper will not be negative


Hi there,

Kinda new to Juce, currently porting some bits of code written for the VST3 SDK to Juce, after some quick debugging of a strange behaviour I came across the following line in juice_VST3_Wrapper.cpp

info.timeInSamples = jmax ((juce::int64) 0, processContext.projectTimeSamples);

I feel like the jmax call will never let negative projectTimeSamples values pass thru … and well, that was the source of the strange behaviour I was experiencing.

Out of curiosity, my question is : what is the rational behind this jmax call for the VST3 Wrapper?


Hmmm that line has been in JUCE since VST3 was initially committed. Many JUCE plug-ins may rely on this number never being negative. What does it mean if this number is negative anyway?


Hi Fabian,

Thanks for answering.
Yes I guess some plugins certainly rely on this number being never negative, I’m just trying to understand why JUCE API is truncating negative values.
I guess you know it’s negative when host is pre-rolling / pre-buffering.
In my very usage, I was just scheduling a Midi event at 0 projectTimeSamples, and obviously this event fired a bunch of times before the host playhead effectively reached 0 projectTimeSamples - i.e. my code is looking if the current processBlock contains the sample number of the scheduled event.
I feel like this logic is working with the VST(2) wrapper, but lazy as I am, I did not try it, just by quickly looking at the codebase.

Again as I am quite new to JUCE, there might be other ways to schedule events that makes my remark a bit curious, still I don’t quite get why JUCE API is firing processBlock (prerollTimeSamples / bufferSize) times with a projectTimeSamples set to 0 (?)


It’s a fair point, I’m also not 100% sure why we don’t allow it to be negative… The tricky thing is that like Fabian said, if we were to remove that now, I bet there are some sloppily-written plugins that would start to fail in the rare situation of getting a negative value.


Hi Jules,

Thanks for answering.
I fully understand the “retro-comptabile” issue.
To be honest (well, I mean transparent), VST ProcessContext is really light IMHO concerning informations it provides concerning host timing context, and mixing Musical and Sample-based timing info will always lead to confusion (personal consideration) at some point, I mean there are a few variables that I always thought should be provided right out-of-the-box like sample-based loop position, sample-based time-signature aware qNote/qBar duration (but yeah, that’s another long discussion) just to say that I packaged all of that in a wrapper that encapsulates juce::AudioPlayHead::CurrentPositionInfo with my own “patch” to JUCE codebase : removing the original jmax

Maybe a future JUCE release could enable/disable the jmax by the mean of directive, so backward compat is assured, and move toward standardisation of projectTimeSamples in future release + 2 - but I feel you already know to handle that sort of things :wink:

Anyway, I did that on my side, so it will break and I’ll get a chance to remember why :slight_smile: