Don't know if anyone noticed... VST3

[Aleksey Vaneev]

If the part that you dislike is how the different pieces are put together, then that's a reasonable point of discussion.

I doubt it is productive, to discuss VST3 anymore. It has been released. Period. But this won't stop me to have my own attitude towards Steinberg's biz. I may be right, I may be wrong, they may be right, they may be wrong - this does not mean anything now given the monopoly situation of Steinberg. VST3 is a given thing, and I (hopefully together with other parties) should act now or be at a loss later, in 3-4 years from now (if not earlier). Steinberg has really shown their attitude. They may start charging you bucks to use the spec - nothing may stop them to now. You may call it my intuition.

[Rock Hardbuns]

There are a few things that make Juce a bad fit as a general solution.
The GUI integration is one. The license is another. Juce is also pretty comprehensive and more or less imposes it's object model. It would be difficult to break out a plug-in spec from it and even if you can, it would end up GPL:ed.

(It would be nice if Jules got involved in this though. He obviously has a good grasp of different plug in standards.)

And the big players don't really have to adopt it as long as it can be easily wrapped.

I guess the point, the way I see it anyway, is to create a new mainstream for developers, not users. To serve that purpose it has to be simple and "universal".

[Rock Hardbuns]

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?

That's true. But I guess it depends on where this initiative ends up. Whether or not it will have a "native" plug-in interface, or just an interface for wrappers.
No reason there can be both, but I think most of those who have voiced an opinion think that wrapability is the priority, and defining a new plug->host interface secondary.

[quikquak]

Steinberg has really shown their attitude. They may start charging you bucks to use the spec - nothing may stop them to now.

If they've made something worse than the Audio Units setup, then it doesn't make any sense at all.

I think many devs would have preferred a simple update, that had things we wanted added to the code we have, like proper surround, and comprehensive evaluation testers - But no.

Dave H

[Crandall1]

Just wanted to add my US$0.02 to the discussion, so we were on the record.

I've been through the SDK, and read everything in this thread, and I have to say that I don't think it's as bad as all that. Adam strongly disagrees with me, and is of the "why the f**k did Steinberg fix something that ain't broken?" school of thought on this matter. Here's what it boils down to, if history is any indicator:

If Ableton supports VST3 quickly, it's game on, and we all have to shut the f**k up and build VST3 plugins. If they don't, Steinberg will rapidly find themselves in the same position as DP, with a unique plugin format that nobody wants to build for, and a market share that would fit in my sock drawer. That's the plain and simple truth of the matter.

Now, that said, the customer (oh, that zany little guy...) has been sold a bill of goods by Steinberg, wherein VST3 IS THE WAVE OF THE FUTURE, and that cat is already out of the bag. It is exactly like AU, really. So many great features! w00t! But ours is not to reason why, and there's nothing to be done about it now except wait to see what Ableton (and to a lesser extent, Sonar) do.

Viz. an open plugin standard. In theory, Audio Damage would happily support such an endeavor (unless it were GPL'd; then we would happily fight such an endeavor) as long as it didn't go the way of the Lord Of The Flies fiesta that GMPI turned in to. Aside from the dumb-ass name, that project was doomed to failure from the start, for any number of reasons, none of which had anything to do with Apple or Steinberg. The people in charge of it were watching Survivor too much, if you want my opinion. (And a perusal of the VST dev list will note that I made this unpopular yet astute observation before that pony even got saddled.)

JUCE is out of the question for us. We can't be beholden to the whims of one single guy for our entire business model. Instead of figuring out how, when, and why to port to VST3, we have to wait for Jules to do it. No thanks. (No offense intended to Jules, as he makes a hell of a product, but that's not the way we do business 'round these parts.) As cross-platform developers in control of our entire codebase, we can move very quickly when one platform gets hinky e.g. the VST2.4/UB fiasco.

Personally, I'm not too worried either way, though. Our code is structured in such a way as to easily make an AU out of a VST without the need for any wrapping. As a result, the new structure of VST3 (which seems to borrow heavily from AU at a cursory examination) isn't really a roadblock. We'll just see about that, though. I'm gonna attempt to port Dubstation this weekend and see what I end up with.

But if Angus et al want to make an open plugin standard that can be its own thing, and easily built out to AU, VST2.4, VST3, well, we'd pay good money for that. And I'd dance a jig. Nekkid. And put it on YouTube.

[Blue Cat Audio]

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.

You are actually right. Just had a look at the Funknown.h header file... It will be COM compatible on windows (because the COM binary spec made compilers change their ABI to be COM compatible), but on other platforms there is no guarantee that two compilers will produce compatible binaries...

This means the SDK also implies a specific compiler... But there is (of course) nothing about this topic in the SDK. I don't remember the changes in the ABI between gcc 3 and 4 but do you think it might impact their framework? I know you can design interfaces that might somewhat be unlikely impacted by compiler changes (because most of them work the same way for basic stuff), but I don't know if they investigated about this topic. (hopefully yes...)

[NiallM]

I'm not sure I've got anything to add to this discussion, but the talk of a new framework/api/etc. to aid the development of plugins for multiple standards definitely interests me. I'm currently considering how best to port my plugins (well, some of them anyway) to work with the new LV2 standard on Linux[1], and this kind of thing could be very useful. I'm going to have to do some kind of wrapping anyway if I want to continue supporting VST (2.4, at least - I see no point in developing for a backwards-incompatible standard that's only supported by one host, that I don't own, and can't even download a demo of for testing in).

Also, it's probably not possible, but anything that would let me license my code under the GPL while still being compatible with VST hosts would be hugely appreciated. As already mentioned in this thread, the actual api/framework/whatever-it-is just needs to allow redistribution of the source files for this to be possible - I don't expect it to be licensed under the GPL, given the commercial interests involved here.

I don't know how much interest there'd be from the Linux developer community, but it might be an idea to post a link to this thread to the LAD mailing list?

- Niall.

[1] Starting with a simplified GUI framework (coming soon, on the off chance anyone's interested) that'll work on Linux as well as Windows and OSX - I couldn't really face porting VSTGUI.

[Aleksey Vaneev]

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 ???

It will cost much. You'll have to buy WUP from Waves, UAD may ask a buck, other vendors may increase major version numbering and require upgrade for money.

But as was said, you'll (as a user) gain nothing except the arse 'wow' feeling telling you are 'cool', 'all new' and 'assembled better than ever'.

The situation is so funny it's unbelievable. But probably I'm just not enough concerned about Steinberg's market share not to laugh.

[Crandall1]

Out of idle curiosity, has anyone actually built aGain and had it show up in the little validator app? I was able to build and link okay, (ignoring the metric fuckload of compiler warnings, as usual), was pleasantly surprised that I no longer have to "touch" the package by copying PkgInfo with a build script, then hit a brick wall. Either the Validator doesn't recognize the unaltered aGain as a VST3, or the Validator is broken.

(This is obviously on a Mac. I don't care if you got it working in Visual Studio.)

I really don't want to have to install C4 on this machine just to prove that either the validator or the build is broken.

EDIT: I'll make a new topic for this. This is a bit under the meta radar for this thread.

[Hippo]

OT

I do not understand any of the technicalities here BUT it it is an interesting thread.

What I do find surprising is that such so many well known plugin devolopers were not part of the official beta program, it makes you wonder who was?

Hippo

[Crandall1]

What I do find surprising is that such so many well known plugin devolopers were not part of the official beta program, it makes you wonder who was?

Snort.

Steinberg isn't in the habit of consulting us for anything. That much should be obvious.

[duncanparsons]

OT

I do not understand any of the technicalities here BUT it it is an interesting thread.

What I do find surprising is that such so many well known plugin devolopers were not part of the official beta program, it makes you wonder who was?

Hippo

wow, joined 2001, with that showing as first post... I'm guessing that your early posted have been archived, either that or you are the world's longest lurker!

Being as I am primarily a delphi developer (who is starting to lean more toward c++, but not yet made the transition), I'm hoping that someone like Frederick Vanmol might join in here. Haven't heard anything from IL in this thread yet...

DSP

[gnjp]

Out of idle curiosity, has anyone actually built aGain and had it show up in the little validator app? I was able to build and link okay, (ignoring the metric fuckload of compiler warnings, as usual), was pleasantly surprised that I no longer have to "touch" the package by copying PkgInfo with a build script, then hit a brick wall. Either the Validator doesn't recognize the unaltered aGain as a VST3, or the Validator is broken.

(This is obviously on a Mac. I don't care if you got it working in Visual Studio.)

I really don't want to have to install C4 on this machine just to prove that either the validator or the build is broken.

EDIT: I'll make a new topic for this. This is a bit under the meta radar for this thread.

you have to make a new folder in /Library/Audio/Plug-Ins called "VST3"
and drop it in that for it to be detected

[puffer]

Chris, though that may have been a purely practical question in a thread that is anything but, it does hint at the future for developers. A lot of figuring out shit all over again, right?

Anyway, If it is indeed "Game on!" it will be interesting to see who could withstand the storm. Though I do wonder if Ableton has any vested interest in switching over. And Cakewalk by Roland? Who knows now, 'cause let's be honest, it would seem wither goes Roland so goes Cakewalk. But I can't imagine their coders are thrilled about having to accommodate a completely different layer of abstraction between the host and the plugins.

I'll take it from observation and the knowledge of people who, you know, actually code (when they're able to dumb it down enough for me grasp) that this is potentially a huge pain in the ass to everyone but Steinberg and, more or less, their users. And that can't be a good thing. Especially for us who are more interested in the fringe of software. From my POV it does seem Stein-aha is preparing to lock shit up in their favor. But, really, I don't know shit. However, how many more VST2.4 Steinberg commercial plugins do you think we'll see?

Honestly, I wasn't even aware of the VST3 spec until it was announced, other than some vague rumblings around the interwebs. (Are we saying that seriously or ironically these days? It's hard to tell.) And I'm huge geeky trainspotter. But I've long since advocated the advantage of getting DSP & instrument plugins out from under the shadow of one company, no matter how you find their business practices. An open standard that had *wide host support* could mean better code and less time spend downloading updates and figuring out why X combination of host/plug cause things to crash. A fresh API written to be as agnostic as necessary would give developers a realistic target to hit.

But *wide host support* is no small hurdle. I suppose Randall's vow to dance naked on the 'Tube is his way of saying "never." The optimist in me likes to see shit like this happen. The realist knows that everyone wants to be the one to establish the standard, to be "right" - to hold the keys that everyone else has to "borrow." The populist in me wants to see an sandbox where everyone gets to play and we reap the rewards. Again, the realist knows everyone wants to be, well, king of the sandbox.

It seems to me that for the idea to get any traction, someone/group need to get pretty motivated and act pretty selflessly. And, quite possibly, need a charismatic leader. In theory, couldn't someone or a small group of coders whip together a really rough API that roughly conforms to VST2.4 and release it under an appropriate license? Then everyone else can have at it? Get one or two adventurous hosts (eXT, whatever that new tracker that was just upgraded for multiple platforms) to include the API. Can an AU/VST wrapper be released as open source? Because that might be pretty necessary for the short term: a good AU and VST2.4 wrapper that would be open to developers to use directly. So, on top of that, developers need to be sold on that API which means a good SDK sooner rather than later - and an SDK that can easily port over to existing standards, right?

Anyway, blah, blah. Point being, yeah, that's a hell of a lot of ifs, ands, and buts. The realist in me says, it's a cool idea but it's never going to happen. The populist still likes to dream.

Could VST3 be the final straw in a long line of relative indignities inflicted upon developers over the years? If the reaction and apparent outcome of this thread are an indication, then quite possibly. But a lot of stars have to line up or someone is going to come up with a really fresh idea.

[mystran]

Now, I still haven't downloaded the VST3 SDK, but so far it seems there's interest in an open API, and like Aleksey(?) said, I also believe the VST2.4 approach of C structures, dispatcher, and a standard entry point (though I wouldn't mind another entry point for getting plugin info without creating an instance) is the way to go. That's not only platform and compiler agnostic, it's also about as language agnostic as it gets. Standard C++ wrapper sure, thought I'd like to see the interface formally specified without requiring anybody to care if somebody's using the C++ wrapper or not (I use C++ but at least Delphi seems quite popular around here).

Anyway, the only concrete suggestion (except for the mailing list announce) I've seen in this thread so far is: Let's have volunteers write a draft specification (one per volunteer), write the basic dispatching layer and a C++ wrapper, then see which one of the suggestions seems most viable, and let that guy coordinate the spec initially? That would get something done, it's not a huge amount of coding (more of design) and would avoid committee problems.

If people want an open standard, I'd say the most important things would be for someone to come up with something that:

1. Exists now in a simple form that people can play around with.
2. Can be wrapped around such that existing hosts can support it.
3. Is properly documented (with keywords MUST, MUST NOT, MAY, SHOULD.. or something equal)
4. Can be extended later.

I could personally write such an API right now (would take a day to draft I guess, a week or two to polish to the point where it'd do the most important parts of VST2.4 stuff), but considering I've not publicly released a single plugin yet (though some are in private circulation) and considering I have zero experience on Mac, I don't think I'm the right person to do it.

If I was doing that, I'd start with something like:

- add a way to specify number of inputs and outputs for audio and midi (in groups for things like 2x2 stereo inputs for normal and sidechain)
- get the processing going, get automation and MIDI input/output there
- add a way for host to provide an editor window and for editor to report back to host, and the host (or plugin) back to editor
- add a way for the plugin to synchronize to hosts time and tempo
- some minor things like reporting latencies and such..

I guess that's what most of the basic effects and synths will need. Add to that an API extension mechanism (something that doesn't require much coordination, like some UUID -> opcode-offset scheme) and one could:

1. develop basic plugins for it
2. wrap it as a VST2.4 (and VST3?) to make it useful now.

I'm sure I forgot something... but you get the general idea...