Yes, I was processing buffers – the problem was actually that the validator did NOT provide buffers, whereas I was assuming they would be there.
Now I skip processing if inputs or outputs are null, or if numsamples is 0, no matter whether bypassing or not.
There are also at least two different interepretations of “bypass,” as you suggest.
One is:
“immediately start copying over input data, keeping old pre-computed state; when bypass goes away, re-use old precomputed state for whatever data comes next.”
This is approximately what you’d get if you “copy and spliced” a chunk of sample data in the middle of a stream, and the plugin essentially was “unaware” of this.
The other is:
“play out any precomputed state/tail you have, but do not feed the input to your algorithm. When the bypass goes away, start feeding the input again.”
This is approximately what you get if your effect lives on a send bus, and “bypass” temporarily mutes the send to my effect.
The SDK actually says in once place that I’m supposed to “copy input data while applying whatever input delay I have.”
I very seldom use bypass myself, although I can think of cases where it would be useful to audition subtle before/after changes. Then again, for the most subtle audition, my “bypass” should actually fade in/out over 100 samples or so, to give a softer turn-on/turn-off transient. Else the transient of on/off will “poison” my ears to the subtle differences that would be there.
Anyway, if someone uses “bypass” for audition, it’s totally OK to apply it only at processing buffer boundaries, and sample accurate automation isn’t needed.
Is anyone doing sample-accurate automation of bypass to generate some kind of dope glitchstep beats? I kinda doubt it …