Thanks! That’s exactly the info i was looking for. That also makes @Jonas answer the accepted answer/solution. But before I do so:
<< The VST3 protocol supports sample-accurate scheduling of parameter changes in plugins . But we do not currently use this because I think most plug-ins out there discard the sample time anyway. Especially if they are ported from a VST2 plugin.
I really want to ask you to reconsider!
I don’t discard it, i think Surge doesn’t discard it, a quick google search says FabFilter doesnt discard it, and there’s probably more.
But what’s more important: many plugs today are indeed rooted in VST2 with a shared code base to VST3. But since Steinberg ditched VST2, there’s bound to be more and more new plugs without the VST2 heritage. I can confirm that I was not even allowed, from the start, to publish a VST2 version of my own plug.
The other big concern in this regard is JUCE. I’d wager over half of all plugs today are JUCE plugs, and JUCE doesn’t do sample-accurate ATM, but it’s been a topic of discussion for years. Once they decide to support it, that opens up the door for thousands of plugin devs to support it, too. Of course that still requires developer effort on the plugin side but i’d be very surprised if none of them did it. And JUCE is huge in terms of user base.
<< This causes quite a bit of overhead, as smaller processing blocks cause more overhead in general. For this reason every host out there will do some quantization here. In our case its ticks, other hosts will use different values.
Agreed. FLStudio is notorious for doing this, up to hand-full-of-samples per processing block. It’s a real performance killer. However sample-accurate just might be on your side here! The question is, is it more performant to schedule 100 blocks of size 10 without sample-accurate, or to schedule 1 block of size 1000 with 100 in-block param updates. Gut feeling says, the latter will be faster but the plug of course has to be able to cope.
I can easily force Reaper to give me multiple updates per block with not even that large blocks (say couple milliseconds or so). Bitwig is even easier since I get updates every 64.
Anyway the point i’m trying to make is this: there’s more and more hosts supporting sample-accurate and as a result I expect more and more plugs to do so, too. Especially when JUCE gets it.
And this might just be me nitpicking but – please don’t assume every plug to play by the JUCE rules! VST3 (let alone CLAP) allows for loads of stuff that JUCE cannot do. This Possible (probable?) bug w.r.t. vst3 parameter flushing was one really nasty example of that which also affected at least one other plugin (i think it was supermassive, but not sure). This Saved automation data does not respect VST3's parameter id, works in Renoise for probably 90% of plugs because most plugs are either VST2 or JUCE-VST3, both in which cases, Renoise is fine. But that thing still possibly breaks many native-VST3 plugs.
Well, end of long rant. I really hope I can change your mind on all of this a bit, but of course TBH i do have a personal stake in this – which is to be able to write music using my own plugin on the only decent DAW that’s a tracker. Still hating piano rolls. And still loving Renoise.
-cheers, Sjoerd