Don't know if anyone noticed... VST3

[griels]

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.

Wow, great minds think alike eh... I was just thinking maybe the time is ripe for such a thing too... Of course there are plenty of prototypes for a new standard, but as old Tone was apt to say, the hand of history is now upon us...

I guess if someone proficient in producing wrappers (can't think who) could provide a 'VST 2.4' wrapper for the standard then it might just prove a big hit

[DrGonzo]

This thread is famous. They are watching every move you do...

http://www.cubase.net/phpbb2/viewtopic.php?t=89729

[mystran]

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.

I still haven't downloaded the VST3 SDK, but from reading the KVR announce, it seems that excluding special Steinberg host support, and possibly some simplifications to certain things, it offers very little (if anything) that wasn't possible with VST2.4 (or earlier) already.

In fact, the VST2.4 is very sensible API for all but minor issues. The parameter naming limit of 8 is one of them. Not being able to advertise an input as a side-chain is another (or is there a way?). Handling VST automation in the middle of a buffer by splitting said buffer, yet handling MIDI messages by sample offsets is kinda curious (though one can translate from one model to another so who cares).

Direct access to host sequencer isn't possible, but I'm not quite sure it's a good idea anyway. Pretty much everything is there, even if not every host supports everything (is there any that supports everything that's been done?).

So personally, the last thing I'd do is panic. I can't see how VST2.4 support would be disappearing from hosts any time soon. An open standard would be wonderful thing to have indeed, but there are two problems with every open standard: committee design and adoption; firstly such standards tend to take ages to grow into overly complex beasts (can we add support for parameters quantized to rationals? should we specify speakers by 3D coordinate per channel?), and the other things is that even when a sensible standard comes out at the end, it'll be completely useless before implemented.

In this particular case, it's little point to even bother forming a committee, unless at least some of the host authors are going to participate, and even then, it should be possible to wrap between an existing API and the new one sufficiently eays that plugin authors can start supporting such new API with sensible amount of work in order to make the API a meaningful thing to support for the major, important hosts, which I assume won't be the early adopters for something completely new.

That said, if you need a "keep-it-simple-stupid" point of view in whatever committee is going to be formed anyway, I'm more than happy to participate. That's going to be the biggest challenge anyway, 'cos complexity tends to be directly proportional to work required to support it.. or the other way around.

That said, I'm ready to admit I'm hugely skeptical considering there's been talk about an open plugin standard as long as I can remember, and the only thing I've seen so far is DSSI on Linux... which if you ask me, sucks.

[griels]

Direct access to host sequencer isn't possible, but I'm not quite sure it's a good idea anyway. Pretty much everything is there, even if not every host supports everything (is there any that supports everything that's been done?).

On the contrary, this would be useful for all manner of plugins. Of course there is room for abuse, but this would certainly provide a marvellous Tower-of-Babel like potential between hosts - for remote collaboration, for intelligent 'freezing' of parts and more.

Just as long as it can be implemented in a host-agnostic way (which it doesn't look like VST3 does)...

[mystran]

Just as long as it can be implemented in a host-agnostic way (which it doesn't look like VST3 does)...

Yup, that's why I think I might not be such a good idea, because if you look at the hosts currently out there, and try to find a lowest common denominator, you can't even give a plugin read access to it's MIDI track, 'cos in certain hosts it might not have one.

Generally, the more modular host you pick, the harder such unification becomes.

[Zynewave]

Just to let you know, we (together with Synapse Audio's developer) have already implemented 'sample accurate' automation in VST2, by introducing 'kVstAutomationType' event type (and the according "canDo"). It carries structure with three values: automation param id, new value and sample offset.

It's really very easy to do, especially if plug-in already supported MIDI CC events.

That's interesting Aleksey. Would you mind sharing the details about this implementation? (my email: info_at_zynewave_dot_com). I was considering doing something similar in my host Podium and the few VST plugins that I bundle with Podium. But I think we all stand to gain if we can agree on a common method of doing this. Maybe we can create a single public-domain header file containing VST2.4 extensions that is agreed upon between various host and plugin developers. I think it's safe to assume that Steinberg will not make further changes to the VST2.4 format, so a few well-considered VST extensions defined by the developer community should not cause any conflicts in the future VST support. If there is interest in this among developers, I have a few things that I would like to share, such as a method for silence-optimization that I currently use in Podium.

I have only briefly browsed the VST3 files, but from what I've seen I'm in no hurry to add VST3 support to Podium. Major VST3 features such as silence-optimization, dynamic IO, audio input for instruments, side-chaining etc. are already doable in VST2.4. The sample-accurate parameter automation is the only thing I miss in VST2.4.

Frits

[JonHodgson]

This thread is famous. They are watching every move you do...

http://www.cubase.net/phpbb2/viewtopic.php?t=89729

And that thread shows one of the problems we'll face, which is similar to the problem faced with Audiounits, and then universal binaries, and it's a customer relations one.

Apple told their customers that audiounits was a super wonderful thing, and dead easy to port to from VST... the punters believed them, so they insisted on AU and got upset with anyone who had problems... they then said that universal binaries would be really easy... again they were believed, again anyone who didn't port really quickly got it in the neck.

Now people are believing Steinbergs hype about the wonderfulness of VST3.

There was sooooo little wrong with 2.4, sample accurate automation (just add a new kind of event to process events, it would take me no time at all to extend that function to handle them), sidechains, and a proper patch handling system.. and/or perhaps better still a way to seamlessly integrate your own patch handling with the host.

The post about how it's only a problem for smaller coders because it means we can't cut corners and that it will lead to better and less buggy plugins made me want to...



I was excited about VST 3 when I first heard about it, now I'm worried.

[asseca]

Just to let you know, we (together with Synapse Audio's developer) have already implemented 'sample accurate' automation in VST2, by introducing 'kVstAutomationType' event type (and the according "canDo"). It carries structure with three values: automation param id, new value and sample offset.

It's really very easy to do, especially if plug-in already supported MIDI CC events.

It sounds interesting to me as well, just a question, why did you choose not to use the already defined "kVstParameterType" ?

It seems a standard structure derived from "VstEvent" logical:

Code: Select all

struct VstParamEvent {
  VstInt32 type;        ///< @see VstEventTypes
  VstInt32 byteSize;    ///< size of this event, excl. type and byteSize
  VstInt32 deltaFrames; ///< sample frames related to the current block start sample position
  VstInt32 flags;       ///< generic flags, none defined yet
  VstInt32 paramID; 
  float    value      
};

Maybe using "vendorSpecific" and "hostVendorSpecific" as handshaking method to enable this function ...

[JonHodgson]

Reading a bit more I see that Aleksey already implemented the extra event for sample accurate automation... see, told you it was easy!!

[whyterabbyt]

well... i guess we'll see. Who knows, only time will tell. I do know waves and virsyn and many others ARE supporting it, so we'll see if the pressure is too strong for other devs to follow. It's all up to them. No one is FORCING them.

and if the pressure is too much for the smaller/independent/one-man developers... what happens then?

[Angus_FX]

mystran - I'm very much of the 'Keep it simple' philosophy too.

Once you start interrogating host architecture like griels is talking about, you open up a massive can of worms in terms of complexity especially as hosts' internal representations of song structure etc. differ so vastly (and may change regularly). Probably the best hope there is for any new API to support a standard way of navigating host-specific dynamic structures, but designing such a thing is no trivial task. You might almost as well fall back to the OS-platform scripting languages like Applescript really.

[peejunk]

I think anyone would agree that standards should be defined by ALL (or at least most of) those that need to implement them, and that the world of audio software is ripe for some open standards.

I advise all devs to contact your coleagues, both host and plugin developers, via email, and present the idea as well as the reasons you've come to this (and the link to the thread) -- in other words: rally. I'm pretty sure most people that are independent of Steinberg will see the spec and everything about VST3 as a way to control competition rather than technology improvement. By some logic, host devs should be more vary of this than plugin devs. It's them who compete directly with Steinberg flagship products.

I personally feel that Steiny has gone a bit too 'wannabe Microsoft' lately and deserves a bit of a cold shower.

If you can sell the idea, and make an open/opemsource API and a SDK that would make both plugin AND host developer transition/implementation relatively painless you might revolutionize the world of audio software in a good way, even if for some short time that means a split in the industry.

I would bite the stick and ignore spoilt end-users for a while (besides the vst2.4 world will tick on for a while, this leaves SOME Cubase 4 users against the army of 3rd party host users, and majority of users of all these tools that simply won't care anyway). Finally, it's them that benefit from choice and openness in the end.

[ObsoleteAcc99]

[DELETED]

[Aleksey Vaneev]

It sounds interesting to me as well, just a question, why did you choose not to use the already defined "kVstParameterType" ?

It seems a standard structure derived from "VstEvent" logical:
Maybe using "vendorSpecific" and "hostVendorSpecific" as handshaking method to enable this function ...

The struct we've used is similar to your example, kVstParameterType is deprecated. CanDo's is a better protocol to check support of this kind of automation.

[Aleksey Vaneev]

That's interesting Aleksey. Would you mind sharing the details about this implementation? (my email: info_at_zynewave_dot_com).

asseca gave the example of the struct. It's the same thing. It's very simple and fully VST-compatible (except being non-standard).