Bitwig does not transmit sample-accurate events at block boundaries

[ofsjoerdk]

Imagine i have a one-second piece of music with an automation curve on the plugin master volume that goes from 0 to 100% in that same second. The host automation curve is just linear between 0 and 1, but the plugin doesn't know that. It's just receiving time-stamped events. Now say I have the host buffer size set to 480 samples and the sampling rate to 48000, so 100 blocks in total.

In order for the plugin to accurately reconstruct the automation curve, the host has to transmit events at positions 0 and 479 for the first block, 480 and 480 + 479 = 959 for the second block, 1440 and 1440 + 479 = 1919 for the third, etc. I think VST3 actually requires this (although repeating the last's block end value at sample 0 of the next block is optional), see "Automation and Playback" over here: https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Parameters+Automation/Index.html#problems.

I also confirmed that Reaper implements it this way, both for CLAP and for VST3. However, Bitwig does not, and instead it only transmits values at t=0 of each block (for the above mentioned example) or every 64 or samples (when using CLAP modulators). Now for CLAP modulation I get the vst3 "trick" doesn't cut it (i.e. what if the modulator is a sine wave) and we have to accept whatever granularity the host gives us. But for user-drawn automation curves, I would expect "sample-accurate" to indeed mean the plugin can reconstruct the host curve on a per-sample basis. If it actually does that or internally uses a multi-sample granularity is up to the plugin, of course.

So, I have 2 questions: 1) Is my interpretation of the VST3 spec correct, and Bitwig is at fault here? and if so, 2) Does CLAP define sample-accurate different from VST3?

[sjoerdvankreel]

Closing, this is not worth pursuing. Every host but reaper behaves like bitwig, which probably means I misread the vst3 spec.