On variable buffer sizes in vst 2 and 3 and other host idiosynchrasies

[noizebox]

Apologies in advance for bringing up an old topic if it has been discussed to death already. But I've been searching through the forums for info on how different hosts handle this, and not found a clear cut answer.

Some hosts send varying buffer sizes to the plugin during processing. The 2 most problematic hosts in this regard seems to be FL Studio and Logic from what I've read. Mostly this is to provide better parameter automation resolution. This is still a problem with those hosts I assume? Though are there patterns to it, i.e. do the host still have a finer "grid" in the subdivisions? i.e, for a max buffer size of 128 samples the host will still give you buffers in multiplies of 8,16 or 32 samples?

Vst3 supports parameter changes with sample offsets, so in theory those hosts that do the "trick" of subdividing a buffer for increased parameter resolution shouldn't have to do it. But is that the case in reality? I.e. do the hosts mentioned above provide a steady buffer size for Vst3 but not for vst 2?

At one point I recall seeing a spreadsheet compiled with information on different hosts, such as default buffer size, if buffer size was always fixed or not, threading issues. It was a few years ago and I don't remember if it was on kvr or some other place though. Anyone know what I'm talking about?

[mystran]

This is still a problem with those hosts I assume? Though are there patterns to it, i.e. do the host still have a finer "grid" in the subdivisions?

Variable sized blocks are NOT a problem (seriously, they are not) and they can happen in pretty much any host. Some hosts like FL are notorious for splitting blocks on a very regular basis, but even hosts that usually send you full blocks can still send you shorter ones in various situations, for various reasons. Deal with it.

There is no grid. A correctly written plugin should deal with any block size that is at most as long as the maximum blocksize specified (including but not limited to blocks of 1 sample, or blocks that are 1 sample shorter than the maximum). If you make any assumptions beyond the maximum blocksize being the maximum, your plugin is simply broken.

[EvilDragon]

Obviously if you process your DSP in internal block sizes in order to save on CPU (i.e. u-he uses blocks of 16 samples, Kontakt and Surge (from the top of my head) use 32 samples, etc.) you cannot really support receiving variable sized blocks from the host... no?

Vst3 supports parameter changes with sample offsets

Yet great majority of VST3 plugins completely don't implement this sample-accurate automation feature. Not even Steinberg's own plugins, AFAIK. In theory it's a good feature, in practice it makes smoothing received automation data harder.

[mystran]

Obviously if you process your DSP in internal block sizes in order to save on CPU (i.e. u-he uses blocks of 16 samples, Kontakt and Surge (from the top of my head) use 32 samples, etc.) you cannot really support receiving variable sized blocks from the host... no?

Yes you can. You just buffer your minimum block internally and optionally report latency.

Seriously, you should not even rely on the maximum blocksize being a power of two, because it could be prime for all you know.

[syntonica]

Isn't there some Divine Law about buffer sizes being only in powers of 2? It simplifies life to the extreme!

It's a pity it was written into the spec. Having a 73-sample buffer doesn't make sense in any universe.

(Except the one where the sentient beings have 73 tentacles.)

[Markus Krause]

The audio-engine of FL Studio is really badly designed. I did measurements with FL Studio and can confirm the issue which is known since more than a decade. I also contacted Imageline for several times about it, but they ignore it since years. Instead they blame plugin-developers for it and introduced 'use fixed size buffers' as an optional setting for 'buggy plugins' .

While nearly all other hosts process blocks with a constant size of 2^n samples like 64, 128, 256, 512, FL Studio processes blocks with a completely random size(312, 45, 52, 1, ...) which changes always. It even goes so far that it can occasionally happen that a block with a single sample (1 sample!!!) is processed. You can easily prove this for yourself when you monitor sampleFrames. The behavior of FL Studio is completely inefficient when it comes towards CPU optimization. A lot of CPU is wasted for the context-switch, the CPU-cache and also the branch-prediction is messed up. As a result crackles and CPU spikes can happen - especially with more complex plugin or plugins that are optimized for block-processing (FFT etc).

[EvilDragon]

That is actually completely fine as far as VST2 and VST3 are concerned. The VST spec doesn't forbid hosts sending random block sizes to the plugin. And benefits do exist, as mentioned earlier in the thread. So it's not an issue, it's by design.

[mystran]

While nearly all other hosts process blocks with a constant size of 2^n samples like 64, 128, 256, 512, FL Studio processes blocks with a completely random size(312, 45, 52, 1, ...) which changes always.

This is just not true. Most hosts will usually give you blocks that match the driver buffer size and most drivers give you 2^n sizes. However, most hosts will split blocks in some situations.

As an example, both Ableton and Reaper (and probably most others, but these two I just confirmed) will split a block whenever they cross a loop point (which makes sense: otherwise the plugin couldn't get the correct time-info after the loop jump). I can't remember if either of them splits blocks in other situations as well, but the point is that a host that will always send you nice fixed blocks of 2^n is certainly an exception rather than the rule.

[arne]

Yet great majority of VST3 plugins completely don't implement this sample-accurate automation feature. Not even Steinberg's own plugins, AFAIK.

That's not completely true. As I converted a bunch of old plug-ins from VST2 to VST3 I added sample-accurate automation support to it. All plug-ins in the vintage-plugins.vst3 file from Cubase supports this.

[EvilDragon]

I stand corrected on that account, then! I remember for a long time in VST3 SDK there weren't any example plugins showing how to implement sample-accurate automation, while it certainly was touted as a VST3 feature. So obviously 3rd party developers were none the wiser...

This was evidented by one of Reaper developers. But yeah, that was 2014, so certainly time has passed. However that was 2014, and VST3 was published in 2008, so 6 years and no plugin examples in SDK for one of the "selling points" of VST3, certainly not a good outlook, don't you think?

Good that it's better now, though.

[arne]

There's still no example in the SDK. Maybe a weak point, but I remember that most features of VST2 were also with no example in the SDK. Check out other plug format SDK examples and you will see that they also lack many examples of their feature set.
On the other side, the note expression feature has an example in the SDK and yet many if not all instruments implement the weak MPE feature instead (even on top of VST3). So it's not that examples will help developers do the right thing, whatever that is.

[EvilDragon]

That's because there are more DAWs out there that support MPE vs note expression... because NE is like this whole new thing (I guess we could say it's a different sort of protocol by comparison) and MPE is just repurposed MIDI, which any DAW with support for MIDI channels can support (nevermind the how easy it is to edit such MIDI, it's still some sort of support).

That, plus MPE is clearly geared towards actual interaction with a hardware device, while note expression is more geared towards piano roll mousing, which is not how everyone always prefers to work. Change my mind!


Either way, MIDI 2.0 should subsume it all, for the benefit of everyone (because then it's a standard defined not solely by Steinberg but by many other involved parties as well, which should hopefully help in better adoption rate moving forward). But we're going off on a tangent I suppose


(That said, I still think it's better to have examples for selling point features in the SDK rather than not.)

[arne]

MPE is such a small subset of Note Expression that it is so easy to map to it. There's even a helper class in the VST SDK which helps supporting this for plugin formats not supporting note expression. I don't get why people implement shaky MIDI CC message parsing by its own instead of relying on a well defined API and use a helper if the API is not available.

[BlueprintInc]

The audio-engine of FL Studio is really badly designed. I did measurements with FL Studio and can confirm the issue which is known since more than a decade. I also contacted Imageline for several times about it, but they ignore it since years. Instead they blame plugin-developers for it and introduced 'use fixed size buffers' as an optional setting for 'buggy plugins' .

While nearly all other hosts process blocks with a constant size of 2^n samples like 64, 128, 256, 512, FL Studio processes blocks with a completely random size(312, 45, 52, 1, ...) which changes always. It even goes so far that it can occasionally happen that a block with a single sample (1 sample!!!) is processed. You can easily prove this for yourself when you monitor sampleFrames. The behavior of FL Studio is completely inefficient when it comes towards CPU optimization. A lot of CPU is wasted for the context-switch, the CPU-cache and also the branch-prediction is messed up. As a result crackles and CPU spikes can happen - especially with more complex plugin or plugins that are optimized for block-processing (FFT etc).

I agree with Imageline here. FL was/is one of the only DAWs to support fairly accurate automation even for VST2 plugins. And it outed lazy devs that built plugins on their expectations from a standard, not the real implementation. You want fixed sizes, either buffer them yourself or explicitely tell FL to use fixed sizes. There is no other way, not in FL, not in any other DAW. We experienced non-max-blocksize sizes in every DAW, you might only see the side effects in FL first because it does it heavily and for good reason, even more in offline processing than realtime.

Cool to see Arne respond in here, maybe he can also clarify something here: viewtopic.php?f=33&t=557388

[mystran]

There's still no example in the SDK. Maybe a weak point, but I remember that most features of VST2 were also with no example in the SDK. Check out other plug format SDK examples and you will see that they also lack many examples of their feature set.

I think examples (in general, not just when it comes to plugin standards) can be dangerous as they can encourage incompetent programmers not to read the documentation. I think in most cases the time spent on writing examples would be much better spent on improving the documentation. These days there are entire armies of programmers who haven't even learned how to read documentation, because there are too many examples for just about everything.

This thread is a perfect example of that. The documentation states that the maximum blocksize is the maximum blocksize and the actual blocksize can vary. The documentation of both VST2 (at least back to VST2.3, but this is also true for 2.4) and VST3 are entirely clear about it. The processing methods have a parameter for the actual blocksize and such a parameter would not even make any sense if the blocksize was fixed.

Yet because people refuse to read (or at least understand) the documentation, we still regularly get these threads where people think it's fine to assume that the blocksize is fixed and/or that it is a power of two. People argue about how "most hosts" will do this, even though it's easy to demonstrate that it's not actually true if one actually bothers to write a plugin to test it.

So please: stop providing examples. Please force people to read the documentation instead.

ps. Note for those without a sense of humor: I am not entirely serious, but at the same time I'm not entirely joking either, because if people stopped copy-pasting examples and actually read what the documentation states, then we would never be having these discussions.