How important is VST3 support for you as a customer

[Urs]

And there are x64 VST 2.4 plug-ins. I make them. But I don't know why that issue keeps leaking into this debate, 64 bit, whether instruction set or audio bit depth, is part of VST2.4.

I think people are just saying them together to represent what they feel would be the ideal format. I don't think anyone is implying that 2.4 can't do 64-bit. Or at least I don't recall anyone saying so?

Brent

VST2 64-bit is a bit of a weird one on OSX. I explained that in depth before, VST2 invites to mingle platform code with API code in the "VST_editor.cpp" or whatever you call it, because VST2 (on Mac) used to provide mouse and key events by itself. Even Steinberg's own example code mixed platform code in there.

And here's the point: VST2 uses Carbon for 32-bit, but it has to use Cocoa for 64-bit.

I've looked into the possibility of porting my VST2 stuff to Cocoa. It is of course possible, but it's way more work than doing VST3 straight away. With VST3 I can use the very same UI abstraction that I already have for my AU Cocoa layer. For VST2 I would have to rewrite the whole thing. Not worth it IMHO.

[Roger-S.]

Well, I have read several pages of this thread, but finally I got bored and kind of p**d off, because there is so much nonsense and it polarizes people.
----

1. For a start, Yamaha doesn't not own Steinberg, although there are undeniable some influences and cooperations, see Roland/Cakewalk or worse Mac/Logic. Normal in some way, because the users of musical instruments may need the software to produce. So, it's kind of a logical step to do some cooperation.

2. I don't understand, why so many people is complaining about "Steinberg wants to implement a new standard to win more market share...". For a start, they made VST free to use for everyone, and helped a lot of people to make a living. Sorry for that expression, but it's like "Don't shit where you eat..." or "Don't bite the hand that feeds". Imagine, they change their policy and say: "From now on, every plugin has to be authorized by Steinberg and therefor paid by the developer."
There has to be improvement, to avoid to stay behind the competing formats.
And there is compatibility with VST 1 and VST 2.x.

3. If a plugin is programmed in SDK 3, you get also 2.4 and AU. I doubt, we'll ever see this kind of compatibility from RTAS (which isn't free by the way). VST 3 is available for everyone, RTAS isn't nor MAS, DirectX is Windows only, AU is Mac-only. This is clearly an advantage in the market. I feel an attitud more like a "As a programmer I don 't want to change the way I work, but VST 3 would make me too, so no."

4. Maybe the most forgotten thing: For whom are we programming plugins? For musicians and producers/engineers. There are needs, that cannot be addressed by another form than VST3 or 3.5, like Note Expression. If a programmer isn't thinking of the user when programming, then he failed. We do not need another Minimoog emulation, we (the musicians/composers) need more and different ways to express ourselves musically. Imagine how music can be improved and evolve with Note Expression alone and with the things to come in future VST versions.

I am hoping, that VST 3 will get more attention, although it's possible, that many programmers might switch directly from VST 2.x to a future VST 4 (who knows, when). I am looking forward to HALION 4, with Note Expression on samples... a dream coming true.
And don't forget...to over 30% VST3 matters. Make the same poll in a year, and there will be more.

Just my two cents...

If you don't agree, I don't mind. I am just trying to remind some things.

Roger

[AdmiralQuality]

1. For a start, Yamaha doesn't not own Steinberg,

You're right, they "don't not" own Steinberg, because they DO.

http://www.soundonsound.com/sos/mar05/a ... leader.htm

You are misinformed on most of your other points as well.

[Roger-S.]

1. For a start, Yamaha doesn't not own Steinberg,

You're right, they "don't not" own Steinberg, because they DO.

http://www.soundonsound.com/sos/mar05/a ... leader.htm

You are misinformed on most of your other points as well.

OK, I accept this one...
Proof me on the rest, the really important things.

Roger

[AdmiralQuality]

1. For a start, Yamaha doesn't not own Steinberg,

You're right, they "don't not" own Steinberg, because they DO.

http://www.soundonsound.com/sos/mar05/a ... leader.htm

You are misinformed on most of your other points as well.

OK, I accept this one...
Proof me on the rest, the really important things.

Roger

I grow weary.

[Richard_Synapse]

3. If a plugin is programmed in SDK 3, you get also 2.4 and AU.

Even RTAS was discussed, so yes this is great.

Unfortunately, however, it is the quality of the wrappers which matter, not the fact that they exist. Dependent on how many implementation holes there is to fix, adapting them e.g. for professional Logic users may take more time than writing or adapting your own wrapper (which most commercial devs have by now, even for AU 64-bit; Alchemy and DUNE just have been ported, for instance).

Richard

[Angus_FX]

Urs - I dunno if there's something particular to your editor code, but we use the exact same (Cocoa) editor panel code for AU x64 & VST 2.4 x64.

2. I don't understand, why so many people is complaining about "Steinberg wants to implement a new standard to win more market share...".

People aren't complaining that there's a new standard. People are complaining because the whole thing has been managed in a way that's toxic to developers and, eventually, users. The rest of the computing world knows how to get this stuff right - community process, open standards, no more complexity than strictly necessary to get the job done, etc., etc.. this really isn't rocket science.

There essentially aren't any competing formats to VST, so I don't know what your point is there. RTAS is, and I imagine, always will be proprietary to Pro Tools. AU is Mac-only and has no real advantages over VST2.4 (indeed, some longstanding disadvantages like no MIDI out).

3. If a plugin is programmed in SDK 3, you get also 2.4 and AU. I doubt, we'll ever see this kind of compatibility from RTAS (which isn't free by the way). VST 3 is available for everyone, RTAS isn't nor MAS, DirectX is Windows only, AU is Mac-only. This is clearly an advantage in the market. I feel an attitud more like a "As a programmer I don 't want to change the way I work, but VST 3 would make me too, so no."

There's a difference between change for the better, and change for change's sake. VST3 is 5% the former, 95% the latter.

Also - on a more philosophical level, it comes to how you see the host/plugin relationship. There are essentially two ways of looking at it:-

* You can think of a plug-in as a largely complete piece of software in its own right (roughly equivalent to a hardware box), and the plug-in API is there just to provide the "cables" that hook it up to the host. You don't get a very tight integration between devices, wiring things up can be a pain in the ass sometimes, but the people designing the devices are free to build whatever they like, as long as the sockets are the right type & the voltages are within spec.

* Or, you can think of a plug-in as being essentially a component or organ within the host. It doesn't have the capabilities to exist on its own, and it'll be built in a way that fits closely in to its host program. You get closer integration and more convenience as a user, but because the host now specifies a lot more of the plug-in's behaviour, there's less flexibility for designers of both plug-ins and hosts (especially those hosts that aren't made by the company that owns the standard).

Well, needless to say I'm much more in favour of the first viewpoint, I love the fact that in hardware you can plug things together that were never intended to be, I don't mind the inconvenience that comes with it. I feel that plug-in APIs should specify the basic audio & midi connections and not a whole lot more. If you take a layered approach to that kind of design & keep the standards open, you can specify just the bare essentials and allow more advanced features to evolve between hosts & plug-ins as time goes on.

Just imagine - there are so many possible ways of handling note expression information, but in the VST3 model everybody is now stuck with a single one, even though future hosts & plug-ins may not really agree it's the best/right way to go about it. With a layered & open standard (think HTTP over TCP/IP.. hope I'm not losing the non programmers among you here), there's so much more flexibility for better approaches to evolve.

And that's why VST3 is a mis-step. SB *knows* all of this, they simply don't care. It's not like VST 1.0 when they had no idea what kind of monster they were creating, and anyway the case for open standards in software was much less established at the time; 2.x was a small and (on a good day) logical set of extensions there. The pattern for doing this stuff the right way is well-established and well-understood, and for whatever reason they're ignoring it completely. And, unsurprisingly, that doesn't get a very friendly reception from developers.

[Urs]

Urs - I dunno if there's something particular to your editor code, but we use the exact same (Cocoa) editor panel code for AU x64 & VST 2.4 x64.

Yes, it might be my code. My VST2 Editor class was based on the ADelayEdit example and has become a horrible mess

[Roger-S.]

There essentially aren't any competing formats to VST, so I don't know what your point is there. RTAS is, and I imagine, always will be proprietary to Pro Tools. AU is Mac-only and has no real advantages over VST2.4 (indeed, some longstanding disadvantages like no MIDI out).

That was exactly my point. For the moment (I mean right now), there is no actual real competition to VST 2, but only maybe VST 3 itself. I am not worrying about NOW, but the future. It's about the fact, that we cannot afford to stick to a technology without developing it, if we want to keep maintain VST as the leading plugin format.

Digidesign (now Avid) bought Wizoo some years ago, and surely it wasn't just because there are good programmers. It was to take advantage of their knowledge in plugin developing. And Avid is opening the RTAS standard, at least in that way, that there are now RTAS plugins in UAD cards for example. What I am trying to say is, it does not depend only Steinberg alone, which plugin format is the important one, the competing formats are able to change too, to take your example, they might implement the posibility to integrate midi out in AU.

But if there is no development in VST, sooner or later another format is taking its place as leader in the market. For this reason it's necessary, to take VST some steps further. Apparently this did not happen in a way, the most programmers would have preferred, I recognize that, but it has been four years now.

There's a difference between change for the better, and change for change's sake. VST3 is 5% the former, 95% the latter.

I try to see it more in that way: If VST 2 is 100%, VST 3 is 105%.

Also - on a more philosophical level, it comes to how you see the host/plugin relationship. There are essentially two ways of looking at it:-

* You can think of a plug-in as a largely complete piece of software in its own right (roughly equivalent to a hardware box), and the plug-in API is there just to provide the "cables" that hook it up to the host. You don't get a very tight integration between devices, wiring things up can be a pain in the ass sometimes, but the people designing the devices are free to build whatever they like, as long as the sockets are the right type & the voltages are within spec.

* Or, you can think of a plug-in as being essentially a component or organ within the host. It doesn't have the capabilities to exist on its own, and it'll be built in a way that fits closely in to its host program. You get closer integration and more convenience as a user, but because the host now specifies a lot more of the plug-in's behaviour, there's less flexibility for designers of both plug-ins and hosts (especially those hosts that aren't made by the company that owns the standard).

Well, needless to say I'm much more in favour of the first viewpoint, I love the fact that in hardware you can plug things together that were never intended to be, I don't mind the inconvenience that comes with it. I feel that plug-in APIs should specify the basic audio & midi connections and not a whole lot more. If you take a layered approach to that kind of design & keep the standards open, you can specify just the bare essentials and allow more advanced features to evolve between hosts & plug-ins as time goes on.

Of course I respect your philosophy.
By definition a plug-in is plugged in into a host, precisely to add more functionality to the host. Without the host it's worthless, unnecessary to tell you that, as you are someone being into plugin programming. Having said that, without the hosts all our efforts to program musical software are worthless. This means, we have a certain dependency here, between the host programmers and the plugin programmers.

There are very few VST 3 hosts out there, so for the moment there seems to be to many customers for VST 3, I recognize that. And I completely agree, that, if something can be made within VST 2 standards, that it's be done in VST 2. But again, we need VST to be developed, to maintain its leading position on the market.

All the best.
Peace.

Roger

[samsam]

But again, we need VST to be developed, to maintain its leading position on the market.


Roger

Who is "we", Steinberg shareholders?

As a musician, I have zero interest in VST or any other format maintaining its leading position and 100% interest in devs making stuff I can use in my music making, hopefully keeping pace with OS updates and developments in tech. Nothing more. People should shape technology, not vice versa.

[Roger-S.]

Who is "we", Steinberg shareholders?

...As a musician, I have zero interest in VST...

We is/are the users. If you are a VST user, you most probably want to stick with the DAW you're using and not change the platform you're working in, because this means a new program, new workflow etc,. money..., so I could be of your interest.

It is now the tendency, that every mayor DAW now has its own propietary format. I clearly prefer the VST format, which is used mostly, because the chances to find the plugin I need for the music I want to make, is greater in another platform.

By the way, VST shareholders don't get a cent from any plugin developed by someone else than themselves .

All the best.

Roger

[Richard_Synapse]

I try to see it more in that way: If VST 2 is 100%, VST 3 is 105%.

Yes, and that's fine as an upgrade. But VST3 is a new standard. It's like throwing away your sequencer in favor of another, just because the other one has e.g. a slightly better piano roll in it. If the workflow and features are vastly different, this is generally not a good idea, having to restart from scratch.

Richard

[HanafiH]

The problem isn't VST3. The problem is the failure of vendors other than Steinberg to create a viable alternative and open standard.

[Benutzername]

I think the best indicator of how good an API really is is the number of people that actually use an API because they want to use it and not because they were forced to because of marketing reasons (or pressure from somewhere else in general). So after 4 years of massive VST3 development I'm only able to find seven free plugins in the kvr data base and not a single of them is classic freeware (= not from commercial vendor) or even open source. This says a lot of the internal qualities of the new 'standard'.

[whyterabbyt]

And Avid is opening the RTAS standard, at least in that way, that there are now RTAS plugins in UAD cards for example.

i hardly think 'letting one more developer have an RTAS license' actually counts as opening the standard.

But if there is no development in VST, sooner or later another format is taking its place as leader in the market.

and why would that happen, precisely?

By definition a plug-in is plugged in into a host, precisely to add more functionality to the host. Without the host it's worthless, unnecessary to tell you that, as you are someone being into plugin programming.

Strictly speaking audio plugins dont add new host functionality, though, so you're wrong. They mostly pretty much conform to one of two sets of expected behaviours; generate new audio (and/or midi) or process audio (and/or midi).

(Note that processing MIDI is something that I dont think Steinberg anticipated. So much so that they eventually tried to fold it into a new, separate standard for no good reason, ie MIDI plugins. Guess which way is easier, simpler, and more successful.)

How they do that generating/processing isnt adding any new functionality to the host, its just different instances of the basic functionality. And as Angus says, that simplistic 'audio and/or midi in, audio and/or midi out' model actually pretty much allowed plugin developers an awful lot of scope that would be denied if the model were less like real-world audio devices.

But again, we need VST to be developed, to maintain its leading position on the market.

Why do you think we need that. I sure as hell dont think we need that.