projectTimeSamples in VST3 wrapper will not be negative

#1

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?

#2

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?

#3

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 (?)

#4

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.

#5

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: