Don't know if anyone noticed... VST3

[nollock]

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

Not acording to Arne. He said if it takes 2 or 3 years to switch to VST3 thats ok, which implys that VST2.4 days are numbered, and VST3 hosts will not always be backwards compatible.

[Rock Hardbuns]

By the looks of it, we are talking about a double abstraction API. An inner layer that serves as the interface for the plug-in it self, and an outer layer that connects to various existing APIs, as well as a brand new format.

Questions that occur to me:
* Could VST2.4 plugs be built without needing Steinbergs SDK. I.e could that interface be reimplemented under a completely agnostic license. This would be important to the Linux people.

* Can the "lowest common denominator" situation be avoided? Are there graceful methods to handle differences in features.


Otherwise: For great justice, take off every zig!

[ObsoleteAcc99]

[DELETED]

[ObsoleteAcc99]

[DELETED]

[Rock Hardbuns]

I dislike software engineering approaches used in VST3. It's unprofessional academism, and should be avoided like a plague.

so Arne, Steinberg's head tech, is basically an amateur?

It's probably a great Steinberg solution for Steinberg's purposes. No need to make it personal with name calling etc.

If the community can provide an alternative path forward... I mean, it's all good.

[plastique]

FWIW, I like this API idea too (maybe the first step to homogenize the plugin standard world a little).
And possibly something a few would have hoped VST3 to achieve.

Two things should IMO be among the top priorities:
- as little as possible overhead by the API wrapping (obviously)
- openness to other non-WIN/MAC-platforms like Linux (32bit/64bit)

Apart from this, everything else I can agree 100% as well.

Questions that occur to me:
* Could VST2.4 plugs be built without needing Steinbergs SDK. I.e could that interface be reimplemented under a completely agnostic license. This would be important to the Linux people.

I highly doubt it. Even if it's possible, it would very likely go into reverse-engineering the VST spec territory, going as far as to not even be able to use the trademark "VST" anymore.
The Linux people will either have to depend on others coding the plugins or get over themselves (like other freeware devs also signing the according license agreement for the particular API).

* Can the "lowest common denominator" situation be avoided? Are there graceful methods to handle differences in features.

My initial thoughts were it should have a "core"-API with the current overlap of all involved APIs.
Plus an "extension"-API to be able to add features that are not common to all APIs at the current time or have been added later. Can't say how feasible this is due to having no experience at all in this area but thought I'll share this anyway.

[Blue Cat Audio]

vst3 hosts are by their very design backwards compatible with vst 2.4.
what would change? why would they on PURPOSE STOP vst 2.4 plugins working?

Because maintaining the code that manages both has a cost. As you said, Steinberg stopped supporting DirectX plugins, which was a pain for many customers. Why wouldn't they do the same for VST 2.x?

So it's just the exact same issue except that there are a lot more plugins that will never get ported to VST3, and I am not sure Steinberg really cares. If major actors migrate to VST3 then they'll be happy with it. That's the reason why I am sad they made it in such a way compatibility is not possible.

[jwatte]

I dislike software engineering approaches used in VST3. It's unprofessional academism, and should be avoided like a plague.

If the part that you dislike is the use of pure abstract base classes to implement interfaces, I'll have to disagree. That part, I think makes a lot of sense, compared to the old-skool function with switch statement of the old API. For example, it is much easier to make type safe, and the dispatch overhead is lower.

If the part that you dislike is how the different pieces are put together, then that's a reasonable point of discussion. It would be great if you could critique the specific aspects that you have a problem with, and more specifically what your problem is, as that could lead to actual understanding, instead of just random whining.

[Angus_FX]

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.

Yes, but this isn't actually COM per se - it's just very like COM.

On Windows, it should mostly be fine, as the compiler ABI is pretty stable (and if it's the same as COM, then Delphi etc. should have no problem calling it), but I don't think a COM binary specification has ever been defined for the gcc compiler on Mac OS X Mach-O, and I have it on good authority that the C++ ABI for gcc is _not_ standardized, and is subject to change between compiler point-releases, which with gcc is pretty much annual.

[nollock]

vst3 hosts are by their very design backwards compatible with vst 2.4.

Not true. VST3 doesnt mandate compatibility with VST2.4. AFAIK.

By the way, in 2 or 3 years the hosts won't just stop working. The user has the choice whether to upgrade or not.

If they have no intention of dropping VST2.4 then why mention a time frame at all? Dont get me wrong, you may be right and 2.4 plugins will still be supported for many years... Well maybe someone from steinberg can clarify on this point, but maybe even they dont know. Maybe the continuing support of VST2.4 depends on how many people embrace VST3.

[nollock]

Yes, but this isn't actually COM per se - it's just very like COM.

On Windows, it should mostly be fine, as the compiler ABI is pretty stable (and if it's the same as COM, then Delphi etc. should have no problem calling it), but I don't think a COM binary specification has ever been defined for the gcc compiler on Mac OS X Mach-O, and I have it on good authority that the C++ ABI for gcc is _not_ standardized, and is subject to change between compiler point-releases, which with gcc is pretty much annual.

As far as I understand it Delphi and most C++ compilers all implement classes in this way. The first DWORD (on 32 bit x86) is a pointer to the vtable. This DWORD acts as both a type identifier, as no two classes have the same vtable, and its the fastest way to implement virtual methods.

Which is exactly the same way COM works afaik.

That said I cant actualy see from looking at the SDK how this is implemented, it actualy looks like they just pass the instances about. There's no C interface so it looks like they are relying on all compilers implementing this in exactly the same way?

[ericj23]

vst3 hosts are by their very design backwards compatible with vst 2.4.
what would change? why would they on PURPOSE STOP vst 2.4 plugins working?

Because maintaining the code that manages both has a cost. As you said, Steinberg stopped supporting DirectX plugins, which was a pain for many customers. Why wouldn't they do the same for VST 2.x?

So it's just the exact same issue except that there are a lot more plugins that will never get ported to VST3, and I am not sure Steinberg really cares. If major actors migrate to VST3 then they'll be happy with it. That's the reason why I am sad they made it in such a way compatibility is not possible.

and seeing as their old buddies at emapple did something simialir with logic 7 I suspect they will drop support. Actually it was worse because no-one got time to get used to the idea with two plug-in types - they just suddenly binned vst and got people to like it - I will never understand apple users

i think vst 3 is maybe a reflection on the times in the computer audio market - the big companies are looking to consolidate their interests - all the companies are congolmerating and the little guy is being squeezed out and he likes of steinberg and emapple use their user base to reinforce itself - trying to keep people used to how their stuff works

i'm a cubase user and i want all my vst's as vst 3 - I know it's not fair but that is how it is

so how much will that cost ???

[asomers]

Hi. You are all aware that Juce abstracts plug-in development AND host development from the individual formats, right? Some complain about the license, but I don't see what's wrong with it. Is it the cost of the commercial license and or fact the the non-commercial requires open-source releases? It patches up the rift between the formats exactly the way you propose to do. Hopefully it will just envelop VST3 and this will be a bygone issue for those who have better ways to spend their time than worrying about the stupid decisions of corporations.

I do agree that the 'lowest common denominator feature set' result of this begs for a new widely adopted standard. But do you really think Apple/Stein/Digi etc. will adopt this format and implement its features (whatever they are)?

[Aleksey Vaneev]

I dislike software engineering approaches used in VST3. It's unprofessional academism, and should be avoided like a plague.

so Arne, Steinberg's head tech, is basically an amateur?

Only if academic knowledge can be called amateur.

[Aleksey Vaneev]

Could VST2.4 plugs be built without needing Steinbergs SDK. I.e could that interface be reimplemented under a completely agnostic license. This would be important to the Linux people.

I think this problem should not be even approached. Linux people should use the new API - why they'll need VST at all, after all?