Don't know if anyone noticed... VST3

[Aleksey Vaneev]

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.

A new API is a must if we want to see good features implemented faster. No problem if some new feature is not implemented in many hosts since as it stays now, alikely not all features get implemented by plug-ins even if host offer them. No lose here. We'll probably need to provide ways of problem-free deprecation.

New API can also help to combine calls of other APIs.

I agree that providing an AU/RTAS/VST2/VST3/<other> layer on top of the API is important, especially if this can be done in a portable fashion. But this part is the hardest one, and should be done incrementally starting with VST2.4 support.

[danv303]

I think it's very difficult for a new plugin standard to gain traction, so a solution like Ben proposes is the most pragmatic path. But I hope that the component could be written in a way that there is clean and uniform separation between the plugin and AU/VST2/VST3/RTAS backends. This layer would essentially be your new API that you write your plugins against. If the component starts getting used widely then the host writers could consider to support this layer directly.

[Aleksey Vaneev]

as it's said over at the cubase forums by Fredo, there is NO pressure for developers to go to vst3, as vst3 hosts will always be backwards compatible with vst 2.4

You do not know what 'pressure' means on the market scene. Pressure started already. It's a psychological pressure, pressure of understanding you'll need it one day. I do not mean VST3 is a problem for me personally, but I dislike software engineering approaches used in VST3. It's unprofessional academism, and should be avoided like a plague.

[Markleford]

While everything should be open and public, Im not sure it will get very far if you have to get 100 people to agree every time we want to nail somthing down. [...] I think that was one of the main reasons GMPI failed.

No, GMPI failed because Apple and Steinberg said, "Screw you guys, we're not going to cooperate."

As arne put it a few posts later:

Let's face it. There won't be one plug-in API. The big players (Digi, Apple, Steinberg, etc) won't follow. They are in direct competition to each other to sell their hosts.

Agreed, and I don't see them changing their minds about supporting an open standard any time soon! Not even as an additional supported API, bridged, wrapped, or otherwise shoehorned.

The best you could do is make an effort to bring Cakewalk aboard, as they were supportive of GMPI before (assuming they'd still be: Ron Kuper, who was big into GMPI, has left Cakewalk since, now doing cool audio hardware work at Sonos). But that's not exactly majority mindshare of the sequencer market.

- m

[Aleksey Vaneev]

I think it's very difficult for a new plugin standard to gain traction

I'm thinking the opposite. There were comments already suggesting that a MIDI Manufacturers Association-alike endeavour will be accepted with a good attitude from many host developers (plug-in developers are historically more passive so they won't likely resist). Nobody really likes Steinberg's monopoly on plug-in spec since plug-in spec is no that much different from MIDI spec. Steinberg have gained enough dividends from VST already, hail to them.

[Aleksey Vaneev]

Agreed, and I don't see them changing their minds about supporting an open standard any time soon! Not even as an additional supported API, bridged, wrapped, or otherwise shoehorned.

It does not have to be a quick transition. Beside that some of us have a 'plan'. Market is such a thing that can make even big players cooperate, depending on the situation.

[Angus_FX]

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.

That's pretty much where I was going with this.. define an API at the core, and then build up a good set of open-source compatibility shims, reusing existing technology where possible -- not only to talk to AU/VST2/VST3/RTAS, but also:-

- provide shims making it easy to use Juce, Infinity, WX, VSTGUI and suchlike for UI
- provide linkage to opensource media APIs like PortMusic

Get the API just right, and the rest should fall in to place relatively easily.. it's a lot of work, but most of it has already been done (in many cases multiple times) for VST2, AU, RTAS, PortAudio etc., and most of that interfacing work is pretty much un-controversial heavy lifting. (OK, there will be one or two thorny parts where we might have to make a conscious decision to override some feature of some other spec, but we can cross that bridge when we come to it).

[VitaminD]

oh and well I was hoping that (somehow I knew it was highly unlikely) the vst3 plugins would be backwards compatible to vst2.4 but obviously this isn't the case

vst2.4 isn't fully backwards compatible with vst2.3, so what did you expect...

well I already said I knew it was highly unlikely, so if you think about that I didn't expect anything... I hoped it would be more robust than it is..

[liqih]

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

I would support that in both cases of a plugin skeleton or a new API as Aleksey said (if I got it correctly)... but a plugin skeleton, as an helper for plugins developers, supporting the AU/VST2/VST3/RTAS standards, seems to me an easier way to manage thru the hosts industry competition which would be against a new API (?). After all we should "just" act like a comunity of medium or small developers and join our efforts to build the tool that we all need.

[asseca]

FYI, any developers:- Ben has kindly set us up an announce-list for organising efforts to develop an open plug-in API. Mail me (angus _at_ fxpansion _dot_ com) if you would like to be involved.

... bump ...

[Angus_FX]

Asseca - did you not get my mail? or are you just bumping for the attention of others who might have missed it somewhere in the 18 pages

[umd]

I don't see why would we need a new vst standard... The current one's fine. I'd rather see a new asio revision for better multi host/card handling

[asseca]

Asseca - did you not get my mail? or are you just bumping for the attention of others who might have missed it somewhere in the 18 pages

Thanks I got the email ...
YES, I am bumping this, because it is easy to skip over a posting, maybe a good idea to start a seperate thread explaining to the developers what the "open plug-in API" is all about ??

[Angus_FX]

Well, I wasn't going to - as I don't want to kick off massive amounts of discussion before everybody that should have a chance to be involved has been contacted - not all of them read KvR regularly, and even many of those who do are at NAMM this week.

(Mike K, Liqih, would be great to have you both on board!)

[Blue Cat Audio]

Hello all,

it seems I am a bit coming late in the discussion . I must say I am quite disappointed by the new SDK as I was expecting something really new yet simple. It seems to me they have just changed to a new architecture (with their COM-like stuff. Huhu, reminds me of Real Audio's SDK 10 years ago), but most of the concepts and issues seen in the previous SDK are the same.

COM-like stuff is ok to me even though I understand some might not like it, but I guess we can argue about "coding style" for years and I am not sure it has any interest. Anyway, we already support DirectX plugins format and I don't think you can beat the old Cakewalk DXi SDK as far as complexity and learning curve is concerned .

My major concern here is the incompatibility with previous versions of the "standard". With Cubase dropping DirectX support and reinventing a brand new plugin format, I really do not understand where these guys are trying to go!

Like many people here I don't really see the advantages for end users. All features are almost already available in 2.4. All I can see is hassle for developpers to port to the new SDK (both for hosts and plugins), and end users having to wait for the various hosts/plugins to migrate. What's the point? Just to be clear: I don't think porting our stuff to VST 3 will be such a pain since we already have our internal plugin api, so I am not complaining about extra work. I am just complaining about what our customers will say when they see they have yet another incompatible plugin format... And with the same name (and no real difference in the features)!!

To finish with, a few personal ideas about specfic features and reactions to other posts (it took me a while to read the whole thread...):

Silence detection: interesting feature, but already done in ours (DirectX and VST), and it's safer when done inside the plugin, which really knows about what's going on... BTW I don't see why this new SDK makes this feature possible for the host. It could already do it with 2.4.

C++ ABI & compilers: no issue here. That's the main advantage of COM: it's a binary specification so you guys won't have to use the same compiler as the host app.

Documentation: where is the doc? I mean, not a Doxygen generated html document just showing the code structure. After reading the entire SDK and examples I still see plenty of room for "undocumented" behaviors but maybe I did not see the atcual documentation? For sure i did not miss the license agreement...).
I am very disappointed these guys did not learn from the past and developper complaints (hosts and plugins). If they really intend to launch a new standard, why not writing a complete documentation describing HOW this API should be used? Samples a great but really not enough. I guess there will -again!- be hours of debugging with every single host on the planet... People may like it or not, and it's pretty old and maybe dead now, but at least we never had "host-specific" issue with our DirectX plugins...

So I guess it's now time to wait for hosts to implement VST3, since Steinberg's policy is to refuse demo versions and NFR licenses ... (Note that Sony offered us NFRs for their latest versions without us having to ask. No comment.)