Selling VST2 after October 2018: Steinberg agreement

[Guillaume Piolat]

IANAL but it seems without a VST2 agreement you also can't release NKS plug-ins... what happens in 3 years when the VST2 agreement stop?

I am quite sure hosts and additional technologies from larger companies like Ableton and NI will have VST3 support in the near future.

That doesn't make NKS VST3-based.

[aMUSEd]

Well it probably could be, but it would be a lot of work.

[wavesfactory]

New updates and new releases will be only offered in VST3 / AU / AAX formats. I couldn't get a license on time.
When VST2 guys come to me asking for VST support I'll need to blame Steinberg. This is, obviously, bad image for me and for them. What a mess.

[Aleksey Vaneev]

Service evolution. (The main issue in VST is here)
The API should be able to evolve and add functionality independently from plugins. As the API evolves, existing plugins should continue to function without modification. All functionality should be discoverable, so that plugins can fully utilize it.[/i]

I think your statement is misleading, VST2 was totally future-proof by its design.

[ghettosynth]

New updates and new releases will be only offered in VST3 / AU / AAX formats. I couldn't get a license on time.
When VST2 guys come to me asking for VST support I'll need to blame Steinberg. This is, obviously, bad image for me and for them. What a mess.

Surely there are enough small developers caught up in this that someone with some legal skill will figure out a way for them to use someone else's license for distribution?

TBH, if not, then your plan is pretty much what Steinberg wants so from their point of view, it was an effective action, no?

[S0lo]

Service evolution. (The main issue in VST is here)
The API should be able to evolve and add functionality independently from plugins. As the API evolves, existing plugins should continue to function without modification. All functionality should be discoverable, so that plugins can fully utilize it.[/i]

I think your statement is misleading, VST2 was totally future-proof by its design.

Can VST2 code be immediately compiled to produce VST3 plugins ?

If not, then the VST API as a whole is not backward compatible. Thats what I meant.

Now we could interpret the terms "backward compatible" ,"future-proof" or "Service evolution" in different ways. But the issue is clear. An API change (2 to 3) required code change on the client side. Thats not a very good design.

[Aleksey Vaneev]

Service evolution. (The main issue in VST is here)
The API should be able to evolve and add functionality independently from plugins. As the API evolves, existing plugins should continue to function without modification. All functionality should be discoverable, so that plugins can fully utilize it.[/i]

I think your statement is misleading, VST2 was totally future-proof by its design.

Can VST2 code be immediately compiled to produce VST3 plugins ?

If not, then the VST API as a whole is not backward compatible. Thats what I meant.

Now we could interpret the terms "backward compatible" ,"future-proof" or "Service evolution" in different ways. But the issue is clear. An API change (2 to 3) required code change on the client side. Thats not a very good design.

You are comparing apples to oranges, sorry. VST2 as is, is future-proof as far as extensions are concerned, VST3 is a completely different specification. It's like saying VST2 is not future-proof because you can't create AudioUnit plugins with it.

[S0lo]

VST3 is a completely different specification.

Exactly. Thats what I'm saying. It SHOULD NOT have been a completely different specification.

Apples should have remained apples. (Edit: No problem with better apples)

[aciddose]

VST2 has major flaws. Some of them include lack of constness, the most obvious example is process(const T ** const inputs, const T **outputs, ...) but using strncpy(buffer, ...) is another clear idiot move.

Other problems include the structures lack size/version members: this means these structures are entirely static and can't be replaced entirely.

In addition as I've already mentioned function pointers should never be included along with data: they should have used getProcAddress(...) or similar and getProcDefinition(...) to specify calling convention, parameters and so on. enumerable functions would also be very useful: rather than just vstmain(...) the exported interface should include bi-directional communication to allow something more like vst_get_types() and vst_create_instance(type n). There are multiple possible definitions although I prefer again c-strings like the effect names: "synth1 (st)" or "synth1 (m)". To deal with sub-types simple token rules can be used: "comma is to be used as a token to separate sub-types and must not appear": to solve for disagreement as to the most applicable token "get_token_string()" could be used!

On and on, there are absolutely huge numbers of improvements that could be made. Many of those are compatibility breaking changes: vst 3 should have been this.

[aciddose]

Code: Select all

typedef const char_t *string_ptr_t;
string_ptr_t delimiters = get_token_delimiter_string();
const int sub_units = get_sub_units();
smart_array<string_ptr_t> sub_unit_types(sub_units);
for (int i = 0; i < sub_unit_types.get_length(); i++) {
 sub_unit_types[i] = get_sub_unit_identifier(i);
}
smart_array<interface_t> instances(sub_unit_types.get_length());
for (int i = 0; i < instances.get_length(); i++) {
 instances[i] = create_instance(sub_unit_types[i]);
}

(BTW: for loops can be replaced with template for_each<> calls and this type of c++ interface could be provided as an example in a c++ reference implementation. It should not be part of the interface itself though since an interface should contain zero implementation.)

And etc.

Another flaw: the callback function should not be passed to the constructor! It should be passed to initialize(instance, ...) since the callback can't possibly provide full functionality during construction (does get_sample_rate() make sense when there is no audio processing and multiple I/O at different rates?) There should be no "get_blah()" in the host callback interface. set_sample_rate(), set_maximum_block_size() and others should be host->plugin commands only. Not having a sample-rate should be a valid condition: if the host never sets the sample-rate, coefficients should never be computed.

All these changes ensure that the plug-ins written are well written and bug free code. The protocol used for communication via an interface should be explicitly defined. That doesn't mean "you must call initialize() then immediately call set_sample_rate()" or other dumb shit like that. It simply means having explicit rules and definitions for everything without being short-sighted or blind to corner cases.

The way VST was developed was haphazard and totally unplanned.

[Aleksey Vaneev]

VST2 has major flaws. Some of them include lack of constness, the most obvious example is process(const T ** const inputs, const T **outputs, ...) but using strncpy(buffer, ...) is another clear idiot move.

Consts could be implemented in VST2.5, that's not a deficiency of specification, only deficiency of public interface. Use of strncpy() is totally understandable, for a C-compatible way to move data. It's much better than using oversized "String" classes. A lot of people forget that VST is not the only spec in town, most plugin producers need a meta-wrapper written to cover all specifications and in such case strncpy() is a much better thing than including code for classes not really used throughout plugin.

Another popular misconception is that plugin DLL needs to define several types of instances of a plugin. First of all, all possible instance types can be covered by a correct input-output and flavor definitions and varying channel configuration support. This was partly done in VST2.4. No need for "mono" instance - simply define your plugin supports 1-to-1 configuration, it's host's responsibility to instantiate your plugin with 1-to-1 configuration.

A second misconception is that a single DLL needs to publish several different plugins. Plugin market does not work that way - a user may buy only a single plugin from you and use another plugin from your competitor. So there's little need in "plugin bundles". If you worry about reusable resources simply move them to a separate shared resource file.

[aciddose]

I was referring to the facts that:

1. The buffer length is not passed in VST
2. Copies are made where the source data should be static

Those are flaws in the specification. Yes they could be fixed in vst2.5 but wouldn't be backward compatible.

That was my point!

If we fix the problems let's just dump the zombie baby out with the bathwater: the baby is dead and stinking up the joint.

Also using arguments like "the plug-in market for X doesn't work that way" is brain-dead and counter-productive, purely negative commentary lacking any support of evidence or logical validity. What makes you think it makes any sense to specify a plug-in interface that solely suits your personal needs? Are you an authoritarian?

For example MIDI UART is used to control everything from stage lighting systems to model railway sets.

[Aleksey Vaneev]

Also using arguments like "the plug-in market for X doesn't work that way" is brain-dead and counter-productive, purely negative commentary lacking any support of evidence or logical validity. What makes you think it makes any sense to specify a plug-in interface that solely suits your personal needs? Are you an authoritarian?

If I bundled Elephant limiter with SPAN analyzer, a lot of people would be unhappy to see Elephant in plugin list while they do not need it. Plugin bundles in a single DLL file is a bad practice. Take it as my opinion.

[aciddose]

Nobody cares about your opinion or feels when we're discussing the facts.

"... but I don't wanna use that feature!"

Then don't.

[camsr]

There sould be better agreement of what both the host and plugin do if either cannot or will not support a given feature.

typedef struct Arbitration