Just wondering, could a DAW loop happen in the middle of a sample buffer in processBlock?
Say you want to loop 4 bars at 120 bpm, that’s a precise 8000ms loop. If your sample rate is 44100, that means you are looping over 352800 samples.
But if your sample buffer size is 512, the loop is over 689.0625 blocks, which means on the 690th block, you should technically handle the loop after 32 samples within the block.
Is that correct, or would the DAW “round” it to the block size and actually loop 352768 samples (7999ms) instead?
If there is no rounding, how can you handle (or even know) if the DAW is loop within the block of samples?
Gut feeling is that the DAW would do 689 blocks @ 512 samples and single 32 sample block, but the only way to really know for certain would be to test. But then you’d really need to test in every DAW to know for actually certain how this is handled.
This is one of those things that is for sure going to be implemenation specific, and one DAW may do it one way, another in an entirely different manner.
could a DAW loop happen in the middle of a sample buffer in processBlock?
Of course, why wouldn’t it? If the buffer size is, say 1000 samples and the loop is 10 001 samples, then the loop would first fill 10 buffers, put the 10 001:th sample in the 11:th buffer and fill it up with the 999 first samples of the loop and so on.
A more interesting question would be how the daw handles the loop point. If you just stitch two audio samples together, you’re likely to hear a click or some other artifact at the stitch point. That’s why you normally fade out the first sample while simultanesously fading in the new, keeping the perceived volume stable. But how do you do that with a loop? Do you play beyond the nominal loop point, while fading out and mix that with a fade in of the start of the loop? Or the opposite, fade in before the nominal loop start and mix that with a fade out before the loop end point? Or use a mix of these two approaches?
@ asimilon → that would be ideal, but I am afraid oxxyyd has a point, if a DAW needs to use x buffers + 1 sample, it is not going to call processBlock on a block of 1 sample, is it?
@ oxxyyd → if that is the case, then how are plugin developpers meant to know on which sample the loop is happening?
I can see you imagine an effect plugin, where this would not matter much (except for the fades as you mentioned), but what about a synth which is tempo-based?
Without testing it’s impossible to say how any particular DAW is handling this.
For your specific use case though, AudioPlayHead::PositionInfo has a getLoopPoints method. I suppose you could take the current getPpqPosition, convert the block length to PPQ[1] and add it to that, if the ppqEnd in the loop points is less than calculated block end then you have to handle a loop within that process block.
[1] this nomenclature has always frustrated me; Parts per Quarter Note was historically a measure of how much a quarter note is divided up into, i.e. the resolution at which a sequencer was able to operate. Unless of course I had misunderstood somewhere along the line!
Why would the plugin developer want to know the loop sample in the first place? You (usually) can’t determine where e. g. bars or beats or other musical contents are situated in a block, so what’s your use case for wanting to know the loop position?
Don’t really know what you mean with a “synth which is tempo-based?” Like an ordinary drum machine?
I chime in on asimilons suggestion to check if the AudioPlayHead::PositionInfo carries enough information for your plug-in to do what you want.
@xenakios → yep that would work fine with me
But I think like asimilon said, there is no way to really know without testing it.
@asimilon → very good point! I guess I would also need to check if the DAW transport is currently looping (thinking it would be possible to create loop points without having the “loop” enabled in the DAW).
But I think this is the part that really drives me nuts developping plugins: all this info, like the ppqPosition, the current BPM, the loopPoints, the time signature, the famous “lastBarPositionInPpq” - all of these are implemented differently in every DAW, sometimes they are not even implemented at all >_<
Thank you so much Steinberg for making these “optional” in the VST standard - that made a mess IMO
(and yes I fully agree with the “ppqPosition” naming, it should be called “positionInQuarters” like it is in the tempoEntries on ARA plugins, it has nothing to do with “pulses/parts per quarternote”)
@oxxyyd → yes a drum machine for example, that needs to be in time with the DAW’s metronome, playing together with the beats and bars. Actually one guy made a presentation at the ADC22 about developping a simple metronome plugin and all the struggles that come with it, that was super interesting: Every Beat Counts - Tempo Sync 101 - Tal Aviram - ADC22 - YouTube
