Don't know if anyone noticed... VST3

[Aleksey Vaneev]

Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.

Agreed, the API should be purely structure based, leaving it open to use it with any compiler / OOP implementation ...

Please do not be over idealistic. It's not a 'zlib' API with several functions only, we need several dozen functions: this should be implemented via dispatcher code.

[asseca]

Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.

Aleksey - drop me a line on email (angus _at_ fxpansion _dot_ com)

Sure, it should be "extern "C"", but it's an inner part of an API. The outer part should be C++, like in VST.

Ths outer part MAY be C++ / Delphi / or any other programming language, including pure assembly ...

The "standard" API shell would then be C++

[dasdeck]

ok, i'm thinking more of an sdk/framework then i guess (still a goot way to enshure more consistence in implementation , by restricting/encapsulateing some things, isn't it?) , and will most likely be no candidate for using wahtever api directly, as i favour some framework over high speed directness.

cheers

D3CK

[Angus_FX]

D3CK - that's right. The API's job is to be pure, clean and simple, the SDK classes are supposed to make developers' lives easy

[ObsoleteAcc99]

[DELETED]

[larsby]

Any word from any host vendor on what they think?

[Aleksey Vaneev]

Steinberg is no way a dominant host producer now

and where did you get THAT info?

Deducing from forum statistics and alexa.com. I'm assuming that Internet activity nowadays relates to userbase, at least should correlate much.

[ObsoleteAcc99]

[DELETED]

[Aleksey Vaneev]

Vst3 _is_ backwards compatible with vst2.4 isn't it?

It's not. VST3-only host can't easily handle VST2.4 plug-ins.

But.... didn't steinberg say that vst2 HOSTS could USE vst3 PLUGINS, without the extra features?

Everyone can use everything. It's always a question of price (complexity).

[nollock]

If there's so much plugin and host devoloper unrest about VST3 why not organize a boycott? Refuse to move to VST3 and in the meantime develop an open source clone of VST2.4, at least if the aim is an open source and language agnostic plugin API 95% compatible with VST 2.4, then arguing over that last 5% shouldnt take to long before a workable open source API & SDK can be released.

The thing which killed GMPI imo was that it had to many divergant needs and ideas and the arguments over the details were endless. Too many cooks. I gave up folloing the list after a few months, it just never looked like ever getting anywhere.

Anyway...

If enough devlopers embrace this route then Steinberg would have to climb down on VST3, or at least keep backwards compatible to VST2.4. If they didnt then as soon as their customers realize all those plugins they love wont work with VST3 Steinberg will be stuck in a huge shit storm.

And if customers complain to plugin developers they can just point them at the VST3 boycott page. If customers see a huge list of developers boycotting VST3 then they will surely blame Steinberg.

As was said earlier, Steinberg is not the immovable force it once was.

My sugestions for the name of the open source api would be

Internaly FST = f**k Steinberg Technology.

Publicly FST = Free Studio Technology.

[asseca]

Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.

Agreed, the API should be purely structure based, leaving it open to use it with any compiler / OOP implementation ...

Please do not be over idealistic. It's not a 'zlib' API with several functions only, we need several dozen functions: this should be implemented via dispatcher code.

I'm not over idealistic, VST2 is purely structure based, just talking about something looking a bit like the VST2 standard, so nothing revolutionary or out of this world is implied ...

I have already disected and used the VST2 API in many "undocumented" ways, there are currently 79 dispatch calls and 49 audioMaster callbacks implemented.

When coding wrappers like mGUI, a Host, and some simple plugins, one do tend to see all sides of the VST specification ...

[kp]

[quote="Aleksey Vaneev"][quote="asseca"][quote="Angus_FX"]Actually, any API needs to be 'C' not C++, as the C++ ABI is not guaranteed between compilers and compiler versions.[/quote]
Agreed, the API should be purely structure based, leaving it open to use it with any compiler / OOP implementation ...[/quote]

Please do not be over idealistic. It's not a 'zlib' API with several functions only, we need several dozen functions: this should be implemented via dispatcher code.[/quote]

And isn't this why we're in the position we are now? Both of you are well-established and renowned plug-in developers, and you can't agree on how an API would work at a fundamental level, let alone the details.

What makes you think that getting more developers together would produce an API in any reasonable time frame? It seems that it's only the Steinbergs/Apples/Digidesigns/etc of this world (the DAW world that is) who will ever get an API written, let alone adopted.

Sad as that may be.

[Ben [Camel Audio]]

It's not a problem to design a decent API considering VST2.4 is almost decent. What's more problematic is to get it implemented by major pro audio vendors in their hosts. I think we should start collecting 'agreements of principle' from them first. After we get consent from ten major host developers we may start working on an API. I believe the main idea is to create a 'similar/competing to VST' API that is licensed freely under something like LGPL (but it's better to create own license, just not to make commercial vendors afraid of association with GPL).

I agree that the main problem is not designing the API but getting hosts to support it. My feeling is that the only benefit in a new API would be if all the major hosts supported it, and thus we could just develop for one standard. The plethora of standards that we have to support is the problem. For as long as some of the major hosts didn't support the new format, we'd be stuck in the same situation as we are now, only with one extra format to support. Having witnessed Apples reluctance to support VST and Steinbergs reluctance to support AU, I think the chances of getting either of these companies to support some new standard are extremely slim to the point of being non-existant. Therefore, we'd be stuck with continuing to develop for multiple plugin formats.

What I feel would be very useful is if we could develop some open source SDK which allowed plugins to be developed in a single form, and included wrapping code for the major standards (VST/AU/RTAS). It could even include some form of GUI framework. The licensing terms of the various standards might make this hard to do, but I suspect there would be ways around this. It would only work if a significant number of companies joined together to do this, and I suppose this is unlikely given everyones investment in their existing codebases. I can dream

Ben

[Aleksey Vaneev]

Sad as that may be.

We've agreed already if you have not read. Basically, an API is C with dispatcher function tied to C++ class.

[Aleksey Vaneev]

What I feel would be very useful is if we could develop some open source SDK which allowed plugins to be developed in a single form, and included wrapping code for the major standards (VST/AU/RTAS). It could even include some form of GUI framework. The licensing terms of the various standards might make this hard to do, but I suspect there would be ways around this. It would only work if a significant number of companies joined together to do this, and I suppose this is unlikely given everyones investment in their existing codebases. I can dream

I think this is as important as developing a new API. This won't break any licenses as long as no original VST/AU/RTAS code is included into the API. However, making wrapper seamlessly compile on the developer's end for all these specs can be a hard task to attain.