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
The older API for CurrentPositionInfo is now replaced by PositionInfo, JUCE already introduces breaking changes list that can ‘break’ things.
Negative position is important and the current behaviour has the following flaws:
It’s actually differ from AU and AAX. Both does provide negative values.
With look-ahead/delay-compensation, many hosts push silent buffers ahead of the actual playhead (on the start of the project). so with current behavior we get many buffers implying playback is continuous but… position stuck on 0 for many blocks.
I have to agree (esp. as the other formats support negative values) this seems reasonable. I’ll run it pass the team there might be something I’m not considering.
)