vst3: maxSamplesPerBlock is a maximum, not a fixed block size

[defiantnerd]

setupProcessing passed newSetup.maxSamplesPerBlock as both bounds of setBlockSizes. In CLAP, min_frames_count == max_frames_count means every process() call carries exactly that many frames; in VST3, maxSamplesPerBlock is only an upper bound and ProcessData::numSamples may be anything up to it. ProcessAdapter::process() passes numSamples straight through as frames_count.

A plugin with a fixed internal render quantum uses that declaration to skip its input FIFO and run with zero added latency. Given a host that declares 1024 and then renders monitored tracks on 32 — Cubase/Nuendo with ASIO Guard, and anticipative-FX schemes elsewhere — it renders a whole quantum for a call carrying less than one, reading and writing past both the input and the output buffers the host owns.

Found from a user report of a wrapped guitar-amp plugin sounding wrong at 32 and 64 sample buffers while 128 and 256 were fine: those two are whole multiples of its 128-frame quantum, so they happened to be served correctly.

The minimum is declared as 32, clamped to maxSamplesPerBlock. VST3 states no minimum at all, so this is a practical floor rather than a guaranteed one — the smallest block hosts actually render — and the AUv2 wrapper makes the same kind of call with 16. What fixes the bug is that min != max, which no longer lets a plugin infer a fixed block size.

VST3 was the only wrapper declaring a fixed size: AUv2 passes 16, max, AUv3 and the standalone pass 1, max, AAX passes two different constants.

[defiantnerd]

Updated: the declared minimum is 32 rather than 1, clamped so it can never exceed maxSamplesPerBlock.

VST3 specifies no minimum, so neither value is something the spec backs — 32 is the smallest block hosts actually render. The property that fixes the bug is min != max either way; 32 just states the practical floor instead of a value no host produces, and lines up with the AUv2 wrapper declaring 16.