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
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?
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.
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
Anyway, I did that on my side, so it will break and I’ll get a chance to remember why