About maintaining parameter values in VST (and setting the defaults)

[antto]

What is totally not clear from the specification of getChunk(): Why is data a 2D array and what does the isPreset parameter mean? I guess data is a 2D array, so we can have a separate block of memory ("sub chunk") for each program, i.e. the j-th byte of the i-th program is stored at data[j].

it's not a 2D array
void** data is a pointer to a pointer
the Host creates a void pointer "void* data" and then passes its address to your plugin, then, you have to assign to that pointer the address of the chunk
*data = reinterpret_cast<void*>(&mychunk);
and then, return the size (in bytes)

[aciddose]

If VST doesn't define "banks", why on earth do you think the format for state chunks is called "fxb" ?

In fact, once again you need to shut your mouth and actually bother to look at and understand the source before you end up here ranting on about stuff you haven't even put the least bit of effort toward researching.

I don't mind really, especially not once or twice. It is just when you over and over repeat nonsense that will definitely in time mislead other people.

Code: Select all

from vstfxstore.h

/** Regular Bank (fxb) identifier. */
#define bankMagic			'FxBk'

...

/** Bank (fxb) structure. */

struct fxBank
{
...

...

Code: Select all

from aeffect.h

	effGetChunk,		///< [ptr]: void** for chunk data address [index]: 0 for bank, 1 for program  @see AudioEffect::getChunk

[KarLoff]

What is totally not clear from the specification of getChunk(): Why is data a 2D array and what does the isPreset parameter mean? I guess data is a 2D array, so we can have a separate block of memory ("sub chunk") for each program, i.e. the j-th byte of the i-th program is stored at data[j].

it's not a 2D array
void** data is a pointer to a pointer
the Host creates a void pointer "void* data" and then passes its address to your plugin, then, you have to assign to that pointer the address of the chunk
*data = reinterpret_cast<void*>(&mychunk);
and then, return the size (in bytes)

Thanks for your explanation! A pointer to a pointer is the typical way to implement a 2D-array in C/C++, but it could as well be away to return a pointer trough an "output" parameter. From the specification it's totally not clear, but with your explanation it makes a lot of sense.

Do you also know how to interpret the "isPreset" parameter?

[antto]

i thought it is explained at least a few times in this very thread
but here it goes again
if isPreset==true - get/set the current program
otherwise get/set the whole bank (in other words, all programs)

[KarLoff]

In fact, once again you need to shut your mouth and actually bother to look at and understand the source before you end up here ranting on about stuff you haven't even put the least bit of effort toward researching.

I'm just trying to sum up these things in order to understand them. There is always an implicit "please correct me if I'm wrong". So if anything is not fully correct (yet), I'm glad if you can help to correct my understanding. But please keep your profanity out of the discussion! Also please don't accuse people of "ranting" when the only person who was using "bad language" in this discussion was in fact you...

Anyway, in my opinion, looking at the source code is completely pointless, as we are talking about interface specification here! Any implementation details, e.g. inside the "AudioEffectX" class or even the low-level C interface, may be subject to change in future versions of the SDK - it has to be regarded as a "black box". And how stuff is implemented on the host's side we even can only speculate. So the only thing that we can assume as "fixed", and thus the only thing that really matters for a VST plug-in developer, is the contract of each function in the VST interface. That is: The function's signature and a specification on what exactly the function is supposed to do, if we decide to overwrite it.

If VST doesn't define "banks", why on earth do you think the format for state chunks is called "fxb" ?

You better ask the VST developers about that. I have no idea what was in their mind. And I'm not a music producer either, I'm a C++ guy. So I can only look at the VST interface, as it exists today. And there is nothing specific to "banks" there, as far as I can tell. People are used to referring to the set of all programs as "the bank", it seems. And with get/setChunk() we can "save" or "load" all programs (aka "the bank") at once. But that's it.

i thought it is explained at least a few times in this very thread
but here it goes again
if isPreset==true - get/set the current program
otherwise get/set the whole bank (in other words, all programs)

Thanks, that's the clear answer I was looking for. It it should have been clear before, please forgive my ignorance

[aciddose]

Looking at the source of the now discontinued interface is pointless because you're interested in interface specification?

Good one...

Guess what, that code is the entire interface specification.

In fact that code specifies an interface. I'm not sure what is so confusing here.

Yes, there are specific implementation details that might come up as questions but you need to in the very least start by looking at the source and then attempting to implement the interface. When questions come up and the answer is not obvious, then it makes sense to ask them.

[KarLoff]

Looking at the source of the now discontinued interface is pointless because you're interested in interface specification?

If an interface has been "deprecated" it means they don't recommend it for new projects and they probably won't add new features, but there still may be fixes. And, most important, it doesn't mean nobody is using it anymore. To me it seems VST 2.x has very broad support in DAW's while support for VST 3.x is just starting up. Also, those hosts that support VST 3.x already support 2.x just as well.

Just think about the situation of the IPv6 protocol! IPv6 has been finished since 1998, i.e. 15+ years ago. Still they can't turn off IPv4 tomorrow, because most people on the Internet are still using IPv4. Establishing new standards takes time. A lot of time...

Guess what, that code is the entire interface specification.

Code can never be a specification. The specification of a plug-in interface is the set of available functions and the contract of each function. Any implementation details beyond that are not part of the specification. For example, any implementation details of a "plug-in calls to host" function are totally up to the host. If the plug-in did rely on a specific host's implementation it will be "doomed" as soon as we try a different host or the hosts gets updated. If, on the other hand, the plug-in strictly relies on the contract, it will work with any host, as long as that host doesn't violate the contract - which would be a severe bug in the host. Of course this applies the other way around, i.e. for "host calls to plug-in" functions, just as well.

[aciddose]

You may ask why we are diving right into a programming example. Well the answer is clear, creating a VST plug-in is easy and we don't want to cloud the issue.

There you are, straight from the horse's mouth. This was their justification for not providing a specification and it hasn't much changed. They did include slightly improved documentation in the source code but a well defined specification was never provided. If it was ever written it would be a surprise to me based upon the twisted implementation of various versions of Cubase.

[aciddose]

Regarding your thoughts on VST2 vs. 3...

Yes, VST2 is the standard at the moment. The idea they would ever turn back a page and "fix" it however is extremely fanciful. I wish they would do this, please let it be true.

The fact is however they would likely go directly to VST5 before they went back to VST2.5.

[aciddose]

Also:

http://lmgtfy.com/?q=vst+interface+specification

Alsø alsø: (a møøse ønce bit my sister)

http://ygrabit.steinberg.de/~ygrabit/public_html/

[KarLoff]

Also:

http://lmgtfy.com/?q=vst+interface+specification

Yeah, I have been looking at that PDF before. Even though they call it a "specification", it's actually more a "quick start" guide. They copy-and-paste'd the examples from the SDK into a PDF file and added some introduction to it. Good for getting the first idea when you look at VST for the first time, pretty much useless for looking up any details. Search that PDF for "chunk" and you get exactly zero hits.

Alsø alsø: (a møøse ønce bit my sister)
http://ygrabit.steinberg.de/~ygrabit/public_html/

I also looked at this site a lot, but their info is often of very limited use

Example:
http://ygrabit.steinberg.de/~ygrabit/pu ... l#getChunk

getChunk

Code: Select all

virtual long getChunk (void** data, bool isPreset = false);

Returns byteSize.

Couldn't be more specific

[aciddose]

So where do you get the idea:

1. The VST2 specification is "deprecated" and not discontinued?
2. There is reason to believe a VST2 specification exists, anywhere?
3. There is reason to believe any function or component of the interface has a "contract" apart from the implementation of the interface itself?

Unless you want to start asking these questions on the VST mailing list (assuming it still exists?) or sending them in to the support at steinberg you will get no better answers than by looking at the code and listening to the authors of existing plugins and hosts.

If you really want you can limit your parameter strings to 8 characters or whatever by strictly adhering to the "official" specification, where it exists. The fact remains though that the specification is rarely present and when it is, rarely obeyed by anyone, even at steinberg.

[aciddose]

Regarding your current understanding of get/set chunk and the definition of "bank": I believe you are still incorrect in assuming this means simply to store a collection of "programs".

If that were the case this function would be entirely redundant. Why would the host not simply call effGetChunk with index = 1 combined with effSetProgram iteratively to store each preset itself, wrapping them in a fxb chunk?

Instead I would argue that as it is currently used, effGetChunk index = 0 requests a block of data as is required to completely restore the current state of the plugin.

Some hosts will also call effGetProgram, effGetProgramName and so on at the same time and reload these values when loading a project/state, but in most cases you should probably store this data in the "bank" chunk to ensure your complete state is saved in all hosts.

For example, there are many other elements of "state" other than just the data available to the host through other components of the VST interface. It has already been mentioned in this thread that there may be hidden parameters. I gave an example as the currently selected color on the GUI, or the currently selected "skin" or so on. Depending upon the type of plugin there may be far more information.

For another example, with paged GUI interfaces it may be desired to store the currently open page so that when the project is reloaded the GUI opens in exactly the same state it was saved.

None of this information makes sense inside a "bank", although they do call it that. VST lacks any method to differentiate between what is merely a collection of "programs" vs. a recording of the complete "state". The option commonly used by plugins is to maintain their own preset management system including their own bank format, treating the VST "bank" as a state.

[mystran]

The sad fact is that the "specification" that you should follow at this point is essentially "whatever works with existing implementations" and/or "whatever the community has informally agreed on." For the most part there is a decent consensus on what is acceptable and what is not. There is a decent amount of disagreement what is actually the best way to do things, but mostly we manage to get our plugins and hosts to talk to each other just fine.

In some cases the community consensus might even disagree with the original written specification. An obvious example is parameter names, with tons of plugins (including tons of big name commercial plugins) returning names longer than the specified 8 characters, so if you were writing a host and allocated a buffer of just 8 characters, you would run into some serious problems. There are probably other such cases where in practice you either follow the spec, or you play with others, but that one comes to mind immediately.

VST isn't a perfect standard .. but if you look at the number of plugins and hosts that inter-operate mostly without huge problems .. you could still consider it a fairly successful one.

[KarLoff]

So where do you get the idea:

1. The VST2 specification is "deprecated" and not discontinued?

Well, it is "deprecated" in the sense that Steinberg now recommends 3.x over 2.x and probably won't put further development efforts into 2.x or provide any help for developing 2.x stuff. Still, they can only "discontinue" support for VST 2.x in their own products. And even that they haven't done yet (at least the latest WaveLab loaded my VST 2.x plug-in just fine), probably because the vast majority of all plug-ins still use 2.x. Anyway, Steinberg has no central switch to "discontinue" support for VST 2.x in any existing VST host. VST host developer will continue to support v2.x as long as they deem it useful - "deprecated" or not. And this can be several decades from now on. For example: VFW (Video For Windows) has been deprecated in favor of DirectShow ~17 years ago (and DirectShow itself was deprecated in favor of MediaFoundation), still people create VFW-based Codecs these days...

There is reason to believe a VST2 specification exists, anywhere?

I only made clear what a proper interface specification is (function specifications + contracts) and what it is not (a bunch of source code). I didn't mean to imply a proper "official" specification exists for VST 2.x - although it would be much desired. Actually, the lack of such a specification, to the best of my knowledge, is why I was hoping the learn the missing details from the experienced VST developers here at KVR.

There is reason to believe any function or component of the interface has a "contract" apart from the implementation of the interface itself?

Well, even if there exists no proper "official" specification that defines the contracts for each function, a de-facto specification has been established. That is the "smallest common denominator" that all the "real world" VST plug-ins and "real world" VST hosts have agreed on over the years. So for each function there's a de-facto contract. I just cannot look this up in some specification! I also cannot learn it from source code alone, unless I study the source codes of all existing VST hosts and derive my own "specification" from that - which would be a Sisyphean task. Instead, when details are unclear to me, asking experienced VST developers seems to be the only feasible way. That and doing a lot of testing myself, of course...