Specific technical questions about VST3, and info for users

[jwatte]

The host can either not recompute the time (and tell them the wrong one), or recompute for each plug-in (and waste a bunch of CPU).

The host must already have the data. Think about it! How else would it know how much to compensate by? All the host has to do is to copy the data it already has into the context structure. Unless the host just chooses to keep that data in the context structure in the first place, in which case there isn't even any need to copy it. Note that the context can be a member or base class of a larger structure that the host sees.

[mystran]

If I read the gcc FAQ answer correctly than gcc has a stable C++ ABI :
http://gcc.gnu.org/onlinedocs/libstdc++ ... x.html#5_8

Well, from being a long time Linux user... and without having bothered downloading the VST3 (probably won't do it before I have a host that supports it, and I have no plans of becoming Steinberg customer so..)

In the past, there was a dark time when gcc updates tended to cause trouble with C++ libraries. I think it was still the case with early 3.0 series. Mostly the cause was incompatible name mangling though. I don't remember seeing a compiler update breaking anything after they standardized that... maybe something esoteric like multiple inheritance could have broke it, but who's stupid enough to use that kind of stuff on a library API is beyond me. Anyway, considering that nowadays (read in the past ten years or so) C++ has slowly gained more ground on Linux desktops, I guess there is quite a bit of pressure to keep the whole ABI stable.

In the open source world, stuff usually happens as soon as there's enough people that need something and are willing to do some work for it. Unfortunately that also means that the gcc ABI will change, if there is ever new important functionality added to C++ that can't be sensibly supported on top of the old ABI. It might be standard now, but until it's at least 10 years old, I'm not going to bet money that there ain't gonna be any revisions.

Anyway, I still dislike C++ APIs 'cos C++ is a language that you just can't say you know well before you've used it in real life for 10+ years. And the really funny part is that some code of mine that was perfectly valid C++ 10 years ago, doesn't even compile with modern C++ compilers, 'cos the damn language has changed in source incompatible ways (ok, not big changes, but it's still annoying to have to tweak sources when you expect a simple recompile).

For a library, the problems are 10 fold, because C++ is also a language where single bad decision can dramatically limit what kind of things you can realistically do (often because somebody f**ked up the resource ownership logic, but there are other ways as well). The more annoying part though, is that wrapping a C++ API is invariably more work than wrapping a C API, 'cos C APIs don't try to force a certain class model down your throat. One good thing about the VST2 C++ API was that it was essentially just a sensibly thin wrapper around the C dispatching mechanism.

Oh, from what I've read here what has been said about said C++ API of VST3 feel sorry for anyone writing plugins in a language that can't talk the platform-specific C++ ABIs natively. That'll mean that someone might have to write a C++ to C wrapper just to be able to wrap the C version for their language of choice then. After all, it is rather well known that if you want a language agnostic library API, then on most platforms C should be the choice for anyone that has a clue. So I guess language agnostic API was not desired.

Btw, is the VST3 API exception safe?

[jouni]

Mm.. I haven't checked VST3, but VST2 allows a host to send a plugin any buffer size shorter than whatever it stated would be the maximum. This means a looping position discontinuity in time is trivially solved by splitting the buffer at the loop point, and calling process twice with the partial buffers. If the plugin gets the time info once per process call, this then allows you to pass the right info for each partial buffer.

...

Does VST3 not allow this?

Should be possible though as long as the block size does not change (as state in FAQ). Don't know exactly how that would translate in Steinberg's terms - I guess some developers would think process is always the size host tells, or that process samples is always fixed. Or something completely different. So it's just up to you all guys to make plugins which respect variable process sample sizes I guess. Not much different from old way - but then again sample accurate automation is strange claim.

So it's safe to say that you should think in Steinberg's perspective. Fixed size buffer process is only the official supported way as it was in VST2 (although many hosts and plugins support variable sizes).

[mystran]

So it's safe to say that you should think in Steinberg's perspective. Fixed size buffer process is only the official supported way as it was in VST2 (although many hosts and plugins support variable sizes).

Quoting VST 2.4 SDK (don't have the 2.3 available right now, but I believe it might have been even clearer there):

Parameters:
inputs An array of pointers to the data
outputs An array of pointers to where the data can be written to
sampleFrames Number of sample frames to process

That's the processReplacing() call. If you are a programmer, you should be able to read that as "there is a parameter which states how many samples the current buffers contain, and then live with that". But that is not all:

virtual VstInt32 AudioEffect::getBlockSize ( ) [inline, virtual]


Returns the current Maximum block size.

Considering that the word "maximum" is capitalized in the documentation, I'd guess it is a meaningful word.

Now a host doesn't need to support variable processing. After all, the host is the one that decides the block sizes. But based on the documentation, I'd say it's about 110% clear that if the documentation is to be assumed normative in any sense whatsoever, then any plugin that can not handle variable buffer sizes is, in one word, non-conforming.

[Crandall1]

Considering that the word "maximum" is capitalized in the documentation, I'd guess it is a meaningful word.

Now a host doesn't need to support variable processing. After all, the host is the one that decides the block sizes. But based on the documentation, I'd say it's about 110% clear that if the documentation is to be assumed normative in any sense whatsoever, then any plugin that can not handle variable buffer sizes is, in one word, non-conforming.

Don't tell this to the FL Studio guys. It will only validate the Land Of Happy Buffer Sizes they live in.

[Rock Hardbuns]

Don't tell this to the FL Studio guys. It will only validate the Land Of Happy Buffer Sizes they live in.

, I was just about to say it myself.
Two facts are not in dispute though: Several hosts depend on arbitrary buffer sizes to attain sample accurate automation. And secondly, it's not that much harder to work with dynamic sizing.

So whether it's a written standard or the defacto standard, it's the standard.

Also, if I recall, ASIO (and ALSA, WDM etc) do not guarantee consistent buffer sizes, so if you are working without abstractions, to minimize latency or whatnot, that problem will trickle down to the plug from the host.

[Chris Walton]

Considering that the word "maximum" is capitalized in the documentation, I'd guess it is a meaningful word.

Now a host doesn't need to support variable processing. After all, the host is the one that decides the block sizes. But based on the documentation, I'd say it's about 110% clear that if the documentation is to be assumed normative in any sense whatsoever, then any plugin that can not handle variable buffer sizes is, in one word, non-conforming.

Don't tell this to the FL Studio guys. It will only validate the Land Of Happy Buffer Sizes they live in.

Where's the problem with variable buffer sizes? It's not like it's hard or anything

Anyway, my question. Who had the absolutely wonderful (and I mean this in the most sarcastic way possible) of doing this:

Code: Select all

enum
{
	// ...
	kResultOk = 0x00000000L,
	kResultTrue = kResultOk,
	kResultFalse = 0x00000001L,
	// ... 
};

I'm sorry, but what the f**k!? This goes against EVERY programming convention regarding true/false EVER. False is 0, true is 1/-1/anything else. I cannot think of anything else ever that broke this convention, and Steinborg should take a good long hard look at the idiot in their ranks that thought this would be a good idea.

Oh goody, I can't write if(blah) or if(!blah) anymore I can just imagine the billions of bugs developers will have tracking down this shit

[mystran]

Don't tell this to the FL Studio guys. It will only validate the Land Of Happy Buffer Sizes they live in.

Considering that so far FL Studio has been the one host I've had the least trouble with when trying to develop VSTs I'd say they don't need to be told how to read documentation.

Honestly though, it's the only host that I own the full version of (at the time I was looking for a Windows sequencer, I did an extensive survey of hosts, and about half of them crashed within a few hours, and the rest were either too damn bloated and slow or had crappy pianorolls or other issues with usability or features... or didn't have a demo like the Steiny stuff.. and all that time the FL demo just worked.. and worked.. and worked.. and I could even finish songs with the save feature disabled just by letting the thing stay open for days), so I guess I could be slightly biased.

[Tonmann]

Just one question: Is there an extended/alternative VST-ID scheme in VST3 now at last? Or are we still limited to 4 chars?! This is something I wish Steinberg would have changed a long time ago...

cheers,
Chris

[mystran]

I'm sorry, but what the f**k!? This goes against EVERY programming convention regarding true/false EVER. False is 0, true is 1/-1/anything else. I cannot think of anything else ever that broke this convention, and Steinborg should take a good long hard look at the idiot in their ranks that thought this would be a good idea.

Well, you have to understand that everyone is allowed to have their own opinions. Unfortunately that includes the not only the idiots, but probably also the vegetable that came up with that.

[Crandall1]

Where's the problem with variable buffer sizes? It's not like it's hard or anything

You don't make delays.

[mystran]

Just one question: Is there an extended/alternative VST-ID scheme in VST3 now at last? Or are we still limited to 4 chars?! This is something I wish Steinberg would have changed a long time ago...

The whole VST-ID was a braindead idea from the beginning. It solves absolutely nothing that the plugin filename doesn't. Actually less, since with filenames the user is able to decide whether he wants to replace an old version of a plugin with a new (compatible) one, or keep the old one around.

Or how about this: I might want a beta tester to have multiple versions of a plugin available. Say I've adjusted some internal parameters and want him to check it really sounds better but nothing broke. With filenames said tester can easily load the both versions into the same host at the same time, yet if he wants to test if one version loads fine in projects built with the other version, he can rename the files easily.

The alternative is to compile the same version of the plugin with multiple IDs. When the number of versions to be tested grows larger this gets pretty ugly pretty fast.

[Tonmann]

Just one question: Is there an extended/alternative VST-ID scheme in VST3 now at last? Or are we still limited to 4 chars?! This is something I wish Steinberg would have changed a long time ago...

The whole VST-ID was a braindead idea from the beginning. It solves absolutely nothing that the plugin filename doesn't. Actually less, since with filenames the user is able to decide whether he wants to replace an old version of a plugin with a new (compatible) one, or keep the old one around.

Or how about this: I might want a beta tester to have multiple versions of a plugin available. Say I've adjusted some internal parameters and want him to check it really sounds better but nothing broke. With filenames said tester can easily load the both versions into the same host at the same time, yet if he wants to test if one version loads fine in projects built with the other version, he can rename the files easily.

The alternative is to compile the same version of the plugin with multiple IDs. When the number of versions to be tested grows larger this gets pretty ugly pretty fast.

Does that mean there is no change on this? Bummer!

[jouni]

It is using class GUIDs. Two per plugin, one for the component part and one for the controller part. I guess you in a sense could have one UI editor and multiple dsp parts too if you are clever.

[Aleksey Vaneev]

The whole VST-ID was a braindead idea from the beginning.

I do not think it was THAT bad, but probably it could support TWO (or more) ids for compatibility reasons (to be sure developer does not make a mess out of customers projects due to some mistake with ID assignment made in a previous plug-in release). Of course chunk load function should be able to receive the ID the chunk was saved with (for the case format changes). The same applies to parameters: they should be associated with plug-in's ID and with developer-assigned unique param-id, with means of versioning (or param-id remapping: was XXX, changed to YYY). Ideally, parameter (automation) range should be remappable as well (e.g. previously saved 0..1 should map to new 0.25..0.5 - or to another value via API call). This way customer's project with automation data will replay correctly with a newer plug-in version, if developer had to change the range of parameter due to some problem or shortcoming. These concerns are not a problem with simple plug-ins, but not so with complex plug-ins. Anyway, it's not so hard to implement these things in a host while it's probably all that can be necessary to guarantee compatibility between plug-in versions.

Self-assigning IDs are a better thing IMO. This is done by Apple:
e.g. com.apple.plugin.xyz. Uniqueness (and ownership) of prefix is guaranteed by ICANN Suffix part's keeping is up to the developer.