Selling VST2 after October 2018: Steinberg agreement

[Dozius]

Reminds me of this (Jump to 28:30 or watch on youtube):
https://www.youtube.com/watch?v=EiffgiRAYUI&t=1710s

The IBM BIOS clone is probably the most famous early example of clean room design. It's even the example given on the Wikipedia page! Cool video.

[Ichad.c]

The annoying thing, more than anything else, is that VST3 doesn't do all the things that VST2 does. It's not a superset of features, it removes a number of things that developers (and ultimately end-users) will expect to see - full-featured MIDI handling for a start.

I wonder if extentions to the SDK3.x are still legally valid as they were with SDK2.x, remember ARA? Was thinking, instead of going nuclear with new non-Steinberg SDKs/APIs or reverse engineering which will probably not work due to time and cost - why not 'fix' the MIDI problems by extention? And by definition also leave the door open for upcoming standards like MIDI-CI.

Let's call it MIDIeX for instance, techical issues aside, if you have buy-in from 3+ popular DAWs to add it to their backend and a dead simple implementation on the coding side for developers(i.e. easy to implement), I think it would work as it is much simpler.

If it works really well it would be a mini coup d'etat by code, i.e. end-users asking on Cubase forums when Cubase will implement MIDIeX

[Funkybot's Evil Twin]

There should be a similar plugin consortium to hash out a common, usable, comprehensible API that everybody can follow and let who ever else worry about what's going on under the hood. How many man hours are wasted trying to make AU vs VST vs AAX vs LADSPA? I waste enough time on Mac vs Windows.

Indeed. There were notions to do such a thing 10-12 years ago when VST3 was announced. I think in the end those involved chose to retain the will to live rather than pursue it, not least because no matter how good the API, there needed to be host devs willing to take it on, and plugin devs willing to code against it. Non-proprietary hosts have enough on their plate supporting the existing cacophony of 'standards,' and plugin devs don't want to spent yet more time on boiler-plate code surrounding their natty algorithm..

Thus, my words usable and comprehensible. And hosts would migrate support to the new universal standard and phase out the old formats where possible.

In the end, there would be only three versions to worry about: Mac, PC, Linux. We already have something like it in Juce, but it suffers because it tries to be all things for all people.

I've had the same thought for quite some time. I'm surprised there hasn't been a consortium of instrument and effects manufacturer's who get together and do just this. Model it off how MIDI came about, where the instrument makers were working together to develop the spec, and basically made it open to anyone willing to implement it (I'm probably oversimplifying). VST/Stienberg, AAX/Pro-Tools, AU/Logic/Apple. It feels like the cart has been constantly getting put before the horse.

I'd love to see companies like NI, U-he, Synapse, Cytomic, Roli, etc. get together and just put together a new plugin format under a general public license. Something that properly implements MIDI (including the recent updates to the spec), makes for easy sidechaining, does things like allow plugins to talk to different instances and transmit audio for one channel to another (for grouping parameters or crosstalk between channels), properly reports latency (allows latency reporting to update in realtime), offers sample accurate automation, compiles easily between Mac/PC/Linux, etc. What happens when the host makers don't want to implement? I imagine a deadline with a few years lead time would be ample warning, and if plugins stopped being released in other formats, that would be the proverbial stick. As long as no one's making money off the SDK, I think a lot of the territorial pissing that currently happens could be avoided. If, for example, Avid and Stienberg didn't want to play, either their users would force them or people might just start looking elsewhere. Depreciate VST, AAX, AU.

Oh, idealism...

[aciddose]

Anybody ever consider making a clean room copy of the API? I guess the biggest hurdle is that anyone interested in doing it has already looked at the VST SDK. Crowd source some freelancers?

You mean like VeSTige?

http://linux-audio.4202.n7.nabble.com/G ... 06190.html

[aciddose]

I'd love to see companies like NI, U-he, Synapse, Cytomic, Roli, etc. get together and just ...

... put together a proprietary format with unnecessary hurdles designed to limit competition?

We've already got that.

https://xkcd.com/927/

They've declared VST dead about 15 times now.

https://www.youtube.com/watch?v=wve7Y8mC2fw

[aciddose]

https://github.com/falkTX/dssi-vst/blob ... aeffectx.h

See the date: 2006

The thing they may not understand is what defines whether something is alive isn't some official fiat pronouncement. A thing is either alive or not.

They seem to be on a quest to stomp it out with their boot without realizing they're stomping their own foot.

It's like "pulled himself up by his bootlaces" in some sick madhouse mirror.

https://www.brainyquote.com/quotes/maha ... dhi_103630

First they ignore you, then they laugh at you, then they fight you, then you win.

[aciddose]

Ideally the outcome of the pending litigation will be a simple pointer to existing case-law stating that within the EU and therefore within all associated treaties implementation is required in order to render a work eligible for copyright protection.

The US has similar case-law based upon the fact that a work is not eligible for copyright protection unless it includes "creative" elements. So therefore a documentation of existing facts (like a header for a program interface or a phonebook) inherently does not have protection.

An interface may be considered "creative" up to the point a description is published or a working model is created. At that point any description of the interface immediately ceases to be "creative" and it is reduced to a simple description of a fact. Like a mathematical constant.

In other words the "creation" had taken place in that instant in time. So the "creativity" carried by the idea was transferred from that abstract to concrete form, whether by transfer to the document in publishing or to the device model, operating software or so on.

The abstract interface presented in the header is then merely an abstract interface used to communicate between two entities such as a host platform and effects plug-in. Both the implementation of the platform and the plug-in themselves are potentially capable of containing creative elements but through the act of communicating renders the method of communication a concrete fact rather than abstract.

So in the case of VeSTige these concrete facts were measured and analyzed which allowed them to be used as the input to recreate a compatible abstract description: the vestage aeffectx.h header file.

867-5309
The numbers drawn on the wall. The numbers he dialed on the telephone.

The fact that concrete facts could be measured by anyone and used to produce an identical (necessarily so: otherwise it wouldn't be accurate and therefore incompatible) reproduction of the abstract description is what renders those facts not eligible for copyright protection. The author is not the sole individual responsible for their existence, they can be reproduced by anyone capable of measuring the concrete facts.

867-5307
Maybe his pen broke and the 7 ended up written as a 9 by the dripping ink? I mean it was a pub toilet so perhaps he was just a drunken fool. Either way if the number were read incorrectly it would not be the number of the individual the author intended, the facts would have been misinterpreted and the result would be wrong. That isn't Jenny's number! It's Jason's! What a world that might have been...

[aciddose]

In software it doesn't work like that. You don't just end up on a romantic cruise with your newfound soul mate boyfriend Jason a la like portrayed in that "wonderful" film Boat Trip.

In the world of programming Jason is more like that friendly goalie who doesn't mind helping out with the overgrown vines in your garden. He's a real pal! ... at least until your arms are vines. "Opps! Sorry pal I didn't mean to! Here let me help you even your limbs out a bit..." "No! Limbs are like eyebrows! STOP WHILE YOU'RE AHEAD!" "*slash slash slash*"

In programming you don't end up on a romantic gay cruise. The program simply crashes and that's it. End of story. You try a different number until it works. Only one number does: the number defined in the header!

[BlitBit]

If the agreement was with me as a person that would give much more flexibility.

I applied using my own name rather than a company and I didn't have any problems (got it back signed after a week or so). With this being a 'last chance' offer from Steinberg I wanted to keep my VST2 options open.

I contacted Steinberg and they told me that if I do not have a company I will enter the license agreement as a private person (leaving the field "Company" empty). If I decide to found a company I just need to provide them with the necessary information. Hope this helps others.

[Aleksey Vaneev]

Oh, idealism...

That's idealism for sure. No company in the "big three" (Apple, Avid and Steinberg) will support the spec. So, in the end we'll only have a burden of new spec without benefits of getting rid of "controlled" ones.

[fmr]

Oh, idealism...

That's idealism for sure. No company in the "big three" (Apple, Avid and Steinberg) will support the spec. So, in the end we'll only have a burden of new spec without benefits of getting rid of "controlled" ones.

Exactly. An opportunity was lost when Apple created AU. They could have teamed up with Steinberg (which, back then, had the only "de facto" standard, given that Pro Tools TDM was hardware based, and AudioSuite was showing that it would have to be upgraded sometime soon) and came up with a new format.

Unfortunately, Apple decided (as usual) to do things their own way, and created "another" format, Mac only (again, as usual). Steinberg answered with VST3, and Avid answered with AAX. Dice were thrown then, and there's no way back, I'm afraid.

[Funkybot's Evil Twin]

Oh, idealism...

That's idealism for sure. No company in the "big three" (Apple, Avid and Steinberg) will support the spec. So, in the end we'll only have a burden of new spec without benefits of getting rid of "controlled" ones.

Yep. I was rolling my eyes at my own overly-idealistic post. It should be that easy, but unfortunately, it's not. It would also be nice if there was some sort of trade group/alliance of plugin manufacturer's to allow you guys to throw some of your collective weight around and push back on the DAW makers, but even that would be costly/difficult to organize and therefore is highly unlikely.

[S0lo]

Why do I have a feeling that at least one of these popular DAWs out there do not have a an agreement?

If it happens, it's a strong card in the hands of Steinberg. They could use it like five years latter or so to start completely wiping VST2 away. Like "Hey, remove VST2 from your host or else....".

In the worst case If they manage to do this with the most 3 or 4 popular DAWs, then VST2 would be practically dead.

I don't even know why I'm saying this since it sounds so oblivious.

[aciddose]

In the end the worst case scenario involves wrappers to handle VST as a temporary solution while old obsolete plug-ins are still used.

My plug-ins have always been in their own format which is far more featured than VST. The wrapper is extremely simple and can be discarded at any time. Honestly the only thing it does is hide functionality. If the interface were exposed directly it would be far more efficient than VST.

All we need is for host authors to agree to implement a common interface with the capability to wrap other plug-ins and boom, VST is gone forever.

Internally the only functions accessed are:

Code: Select all

	struct callback_interface_t
	{
		callback_interface_t() {}
		virtual ~callback_interface_t() {}
		virtual void set_preset(const int index) = 0;
		virtual int get_preset() = 0;
		virtual bool resize(const int x, const int y) = 0;
		virtual void parameter_changed(const int index) = 0;
		virtual void preset_changed() = 0;
		virtual void update_display() = 0;
	};

I'm sure other plug-ins probably use more host functionality than my super basic synth/effects plug-ins. The interfacing I use was used in my tracker way back in ~1999 which supported "plug-ins": a delay and a reverb. The only function added since then is "resize(x, y)" for the resizable GUIs.

So I'm sure there could be some arguments regarding which host features are needed or not like greasy speaker arrangements or other such nonsense. I'd prefer for such esoteric purposes that a separate API be used however. VST did include such a thing ("vendor specific") but it was never used in such a way because they decided to make VST greasy instead and just slather on the grease and get it grubby all over. Also the implementation was a bit trash so no wonder it was never really used.

Ideally such extensions would pass pointers of two kinds: void * and const char * (UTF-8 only, absolutely no wide-char) or uint8_t * for data.

"Opcodes" would be simple strings that return a pointer. So this would be identical to GetProcAddress() for example and the interface client would be responsible for populating their own structures with function pointers as needed.

The complete interface would be essentially a standard for querying the interface regarding capabilities and requesting function or data pointers. That's it!

What would be built on top of that would be up to host authors: obviously only the "common" feature set would be supported everywhere. In order to ensure the openness of the standard each pointer (function or data) would be possible to query for its structure: a c++ "POD" struct following standard rules or a cdecl/stdcall prototype with calling convention specified.

So for example knowing absolutely nothing about the interface except for the entry point / query function, one could query the interface and learn absolutely everything it offers.

For your standard "sdk reference implementation" this process would be entirely transparent and function exactly as VST does.

[camsr]

Cross-platform compatiblity was never the responsibility of Steinberg with regard to VST2. It's an interface as aciddose eloquently put it, and much of the SDK is just providing the barebones implementation of what could be done (if the host supports it). The interface is largely platform-agnostic; as long as a platform can support the datatypes in use by the interface, it works, regardless of OS. A VST2 plugin does not even need to be a DLL!