Don't know if anyone noticed... VST3

[Aleksey Vaneev]

err, if you carefully read this thread, that is what most of the developers posting here have in mind ...

Not quite that. 'uber API' is what every plug-in developer already implemented. What we need is a new stable ground for our future. For example, I need a couple of features Steinberg may not be interested in implementing at all. But an API for such function could be defined without Steinberg's involvement (I've already shown a way to implement sample-accurate automation here). It is incorrect to assume that plug-in API can be defined 'from top to bottom' (i.e. from host to plug-in) only. API can be seen as a binding element with both plug-in and host developers adding features to it.

Right now there is no way a plug-in developer can see a feature implemented in a host. I had good results working that way with Cakewalk (and Synapse Audio) so far, but via non-standard VST tweaks only, of course.

[Rock Hardbuns]

The Linux community has been flailing around trying to establish plug-in standards, but ironically no one attained "center of gravity" until the VST ports.
However,with a new independent API that allowed for easy porting and/or wrapping of VST 2.x plugs I think the Linux audio community would jump on board, because they like to be able to GPL their stuff.

Especially if there is minimal reference host and plug-in examples available in the public domain, and the standard as such is released independently of any particular SDK that imposes licensing restrictions.

So if an independent standard could attain the following:
* Native support among the small and mid-sized hosts.
* Easy to port to from VST2.x.
* Availability of runtime converter plug-ins for VST3, AU and maybe RTAS.

..It would become very attractive as a main format for a lot of developers. Maybe not the biggest, but that's their loss.

[danv303]

Instead of writing a plugin API from scratch, would it be feasible to use/extend an existing open API? The DSSI spec was extended from the LADSPA effects spec and fills a similar niche to VST. There is even a wrapper for DSSI/VST plugins that is used by some Linux hosts to get VST compatability.

The plum would be saving a ton of work in nailing the "base" specification and not re-inventing the wheel. Then continue writing your plugins to the new spec and use the DSSI-VST wrapper to target hosts without native support. Of course, the standard will live or die on getting 3rd party host developers on board.

[Aleksey Vaneev]

Instead of writing a plugin API from scratch, would it be feasible to use/extend an existing open API? The DSSI spec was extended from the LADSPA effects spec and fills a similar niche to VST. There is even a wrapper for DSSI/VST plugins that is used by some Linux hosts to get VST compatability.

GPL license may ruin the whole endeavour considering we are on commercial ground. I would not like to have code under GPL in my plug-ins. I think license should be far easier: public domain, with copyright left and the list of participants (those who agree to be on the list).

(there is no need to protect ways of use of the API via any serious license since there is basically only one way to use it: in host<->plugin communication, this API is useless if not supported widely as a whole).

[Rock Hardbuns]

Of course, the standard will live or die on getting 3rd party host developers on board.

The best way to achieve this is to make it a spiritual successor of VST2.x. Preferably so close that a host developer feels like he (or she) is killing two birds with one stone in implementing the new spec. Depend on similar mechanics and so on.
The same is true for motivating people to port their plugs, as well as encouraging SynthEdit and it's brethren to join in.

[Urs]

Hey,

it gets interesting here

I'm a bit confused as to what we're talking about. Is there a need for a full blown API with its own dispatcher and all, or are we talking about a basic plugin skeleton with interfaces to plugin apis and platform specifics?

I think that a full blown plugin thing is overkill because we'd also have to define the whole hosting side. I'd rather define the basic skeleton to which we add the required interfaces. One of these interfaces can then be a self-contained plugin while another interface could be a stand alone application (with Midi/Audio Support).

Cheers,

Urs

@arne: No hard feelings, but I think it's 4 years too late and the way it's marketed (see ttoz etc.) is not acceptable. I won't have many problems with it but I'm tired of these transitions.

[nollock]

GPL license may ruin the whole endeavour considering we are on commercial ground. I would not like to have code under GPL in my plug-ins. I think license should be far easier: public domain, with copyright left and the list of participants (those who agree to be on the list).

As i remember it the problem is simply that steinberg does not allow redistribution of the SDK. So if you use an open source licence, or code that has an open source licence, that requires full distribution of source code then your screwed.

So all that is needed is that the SDK source can be freely distributed.

[Angus_FX]

Hi Urs,

An API defines the contract between plugin and host and can be extremely lightweight (it defines the whole hosting side already). A plugin "skeleton" sounds like a low level SDK component, and is probably more complex in fact.

Assuming this effort makes it as far as the SDK implementation phase (not something that should be taken for granted), I'm sure there are lots of people who are capable of contributing code to shim it to VST2.x, AU, RTAS (for those that have access to the Digidesign SDK), or various kinds of standalone. In fact, it's quite feasible to build one bundle or DLL that implements all of the above, as a modular set of static-linked libs (+source) included in the SDK.

nollock - that's pretty much it! Being "GPL-compatible" is not a particularly big burden for an open SDK.. you can even release it dual license BSD/GPL or similar.

Cheers,
Angus.

[danv303]

Well DSSI is LGPL which is not the same as GPL - it means that any changes to the api code* must be made available, but any client code that uses does not. I think the idea of this clause was to prevent anyone from extending the standard in an incompatible way. I don't think it can be worse from IP standpoint than linking to proprietary licensed code, as is the case with the VST SDK.

Urs - a plugin skeleton would also be a good solution and certainly easier to achieve in the short term. However, it still leaves you at the mercy of the big company spec writers and their own agendas may not align with yours.

(* that is distributed)

[Aleksey Vaneev]

I think the idea of this clause was to prevent anyone from extending the standard in an incompatible way.

Then LGPL does not serve this purpose as anybody can release their own branch of API. I think there are no needs in having any serious license beside political ones. API is not a software product, it's only a junction element between software products.

[danv303]

Yes, anyone can make a branch, but since the branch source must remain open compatibility can be ensured with changes that get wide distribution.

Anyway, I don't want to get hung up on the licensing issue - you know better than me the kind of license that would suit your business. DSSI is just one reference point.

What would be great is if a group of respected community developers from the commercial world defines a common standard under a friendly license. Interoperability (probably via a wrapper layer) with existing standards, design simplicity and platform neutrality would be great to have, as these were the things we liked about VST 2.4. It sounds like Angus wants to get the ball rolling on this - I hope other commercial and freeware developers get behind the initiative and can co-ordinate well enough to get something real out there.

[liqih]

well... i guess we'll see. Who knows, only time will tell. I do know waves and virsyn and many others ARE supporting it, so we'll see if the pressure is too strong for other devs to follow. It's all up to them. No one is FORCING them.

and if the pressure is too much for the smaller/independent/one-man developers... what happens then?

The Third World of VST users will be created, where the goal would be more music than technology advance and money,

obviously I'm not against new technology development, but IMHO the current technology is underused in music,
so trying to pushing that VST3 in the market right now is just lame business for money

[Ben [Camel Audio]]

I'm a bit confused as to what we're talking about. Is there a need for a full blown API with its own dispatcher and all, or are we talking about a basic plugin skeleton with interfaces to plugin apis and platform specifics?

I think that a full blown plugin thing is overkill because we'd also have to define the whole hosting side. I'd rather define the basic skeleton to which we add the required interfaces. One of these interfaces can then be a self-contained plugin while another interface could be a stand alone application (with Midi/Audio Support).

I was envisaging the latter of the two things you're describing - plugin skeleton with interfaces to AU/VST2/VST3/RTAS. Having seen Angus reply, I'm prepared to consider the API alternative, as he has more experience of these things than me - but I do think its critical that the main focus should be on supporting the AU/VST2/VST3/RTAS standards and this should be at the very centre of the project, and not an afterthought. Another plugin standard is I feel the last thing we need - but an open source project where we provide wrapping to all standards and which we all keep up to date would be a fantastic thing for the whole industry, I think. If we did develop an API, I suggest something inspired by VST2.4 with appropriate extensions (eg. time stamped automation) and necessary changes to allow VST3 porting would be a good place to start.

Ben

[Mike from reFX]

I 100% agree with the previous comment.

[ObsoleteAcc99]

[DELETED]