Don't know if anyone noticed... VST3

[dasdeck]

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

in case of vst ist a collection of methods/functions, wich get published in a dll or kind of, accasible from the host and the plug in right?
i read sometimes about problems host and plugin devs have with each other becouse this technically ralatively "loose" or unrestricted API (vst) gets implemented slightly different (or not so slightly). shouldn't implementation of the API technically be at least restricted far enough (through encapsulation in classes for example) to avoid those differences in implementation , and if there are differences left , so they don't matter that much?
shure , it may result in slower code,but may also bring more stability and predictability of plug in host behaviour.
i wonder if this can be done witch a bunch of API functions? i guess the restrictions will be on paper then, but not technically give. i guess this should be done with a littel object model.
also is think when "we" make an api, we should provide tools (a little SDK or framework around it that restricts/suggests the implementation ) to make implememtnation for host / plug devs very painless.
so maybe create just the basic api, consisting of a buch of methods/functions, with vst in mind (maybe even add a wrapping layer for quick porting of vst plug ins) and add the tools to bring a "guide" to enshure consistent implementation in plug is and hosts.

D3CK

[asseca]

dasdeck,

Slower code is the last thing we want, in the "real-time" audio scene programming-wise we are looking for maximum speed ...

As Angus_FX wrote the API should be as simple as possible ... and hopefully better documented than the VST2 spec ...

THe SDK classes can then attempt to make the interfacing to the application code "foolproof" ...

[asseca]

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.

I think that we all agree that VST2.4 is close to perfect, most of us hoped that Steinberg would just add the missing bits, and maybe fine-tune a few bits, unfortunately with VST3 Steinberg has now taken the "bloatware" route ...

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.

Making a new API is not that difficult, but as many has pointed out the major concern is if enough host and plugin developers will support such a move ...

[Angus_FX]

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

Tempting, Ben, very tempting!

I reckon between the people talking here the know how exists (heck, I could do most of it single-handed if I had to).. the question then becomes how to make the business side work, we are talking about a substantial undertaking as well as something that would more-or-less kill off VST-AU and VST-RTAS (well, if VST3 doesn't manage to do that already ).. however, if push comes to shove...

[Chris Walton]

I've been collecting and writing up thoughts for something like that as well. Maybe somebody should make a mailing list/forum somewhere where we can sign up and discuss this...?

[Ben [Camel Audio]]

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.

I'm glad we agree about the importance of the wrapping code. I agree that getting the wrapper to seamlessly compile could be tricky - but we all face similar problems individually, so it should be doable. I take your point about not including the VST/AU/RTAS code - looks like its a non issue. One approach to the problem would simply be to create open source wrappers for VST 2.4 plugins. AU/RTAS is definitely doable - the main problem would seem to be supporting VST3 due to the model-view-controller approach that Angus mentioned. If anyone has any thoughts on wrapping VST2.4 as VST3, then I'd be very interested to hear. If thats not possible, then perhaps we'd either have the model-view-controller pattern forced on the new API. It will be interesting to see how quickly and widely adopted the VST3 standard is - I wonder if/when Steinberg will drop VST 2.4 compatibility.

Ben

[dasdeck]

dasdeck,

Slower code is the last thing we want, in the "real-time" audio scene programming-wise we are looking for maximum speed ...

As Angus_FX wrote the API should be as simple as possible ... and hopefully better documented than the VST2 spec ...

THe SDK classes can then attempt to make the interfacing to the application code "foolproof" ...

yes, pretty much what i tried to summarice at the end of my last post.

i just suggested to deliver this kind of "implement the API fool proof" SDK along with the formed API, to make it more attractive.

of course i know high speed is highly appreciated in "realtime" applications, but this high speed can be lost, if developers have to compensate for strange implementations of the API in the corresponding counterparts of hosts and plugs. i did not mean to make it unnescesarryliy slow. just to nearly fool prof the interfacing. also today i would not mind spending a few more cycles in a non blocking manner to increase stability and compatiblity a lot.

i remember a post by Aleksey Vaneev where he compared the cpu cycles taken to get a timing information form the host, the differnces where huge. while this may not be the most crittical thing and not the best example for what i mean, it shows what unpredictabilitys the devs must deal with. regarding host A it is no problem to call for the timing info frequntly (as it takes almost no CPU) regarding host B its rather time consuming. another example. i have programmed a little juce plug in , it just worked fine in erngy xt 2. but in reaper it crahed (failed the plug in scanning even), and you know why? becaouse i tried to politly end a maybe running thread in the plug ins destructor (wich may be a no no and absolutely my fault ,and seemed not necesaryy anyways (must investigate further btw) ,). the point is the difference. both hosts (and plug ins too) should share the same routines to deal whith that kind of stuff i think.
I must admit that i really like the idea of a new API (+SDK) wich opens practically kind of open sources VST 2.4 due to a big similarity. put a wrapping layer on top for quick porting of existing VSTs and it could be adopted pretty quick and i would like to take part of it .



D3CK

[docdued]

Why not go with JUCE? It's pretty close to perfection already, if you ask me... and all you talented people would be more than welcome to help developing it further. Of course there is one mastermind behind it who ultimately determines the route, but I don't think that's necessarily a bad thing.

[asseca]

Why not go with JUCE? It's pretty close to perfection already, if you ask me... and all you talented people would be more than welcome to help developing it further. Of course there is one mastermind behind it who ultimately determines the route, but I don't think that's necessarily a bad thing.

Unfortunately in my case mGUI and JUCE won't work out, Also I personally think JUCE is already too high level blocking out original "tricks" ...

[Ben [Camel Audio]]

Tempting, Ben, very tempting!

I reckon between the people talking here the know how exists (heck, I could do most of it single-handed if I had to).. the question then becomes how to make the business side work, we are talking about a substantial undertaking as well as something that would more-or-less kill off VST-AU and VST-RTAS (well, if VST3 doesn't manage to do that already ).. however, if push comes to shove...

I do see the business problem regarding VST-AU and VST-RTAS, and I don't have any easy answers to that one - but I definitely sympathise. If you or anyone else whats to discuss stuff off list or in the other kvr dev forum, I'm happy to chat about it. As far as possible, though I think discussing such a project here on this forum would be ideal. It might also be good to get Magnus involved as he's got a lot of experience in this area - though I know he's starting to get rather frustrated with plugin format changes - not sure if that makes him more or less likely to want to be involved

In any case, I do think it would be fantastic thing if we could get a project based around open source wrappers for the main platforms going. Just think - every time Steinberg/Apple changes the formats, only a couple of us would have to figure out how to keep everything working, and we wouldn't have to do it on our own - rather than about 50 different people tackling the same problems as happens now. We'd all be more productive and get to spend more time actually developing new products - it would be a wonderful thing

Ben

[dasdeck]

Why not go with JUCE? It's pretty close to perfection already, if you ask me... and all you talented people would be more than welcome to help developing it further. Of course there is one mastermind behind it who ultimately determines the route, but I don't think that's necessarily a bad thing.

juce does not change anything to the actual API.

i for example would like to have dynamic nubmer of I/O (VST 3 would bring this). posibility for complete 64 bit siganl path (already there?)
multiple midi ports (usefull for host like nergy XT to control more then 16 vsti). and dome more (real resizable GUI, not just "hacked" ).

it would be cool if the SDK fro the api would be juce like thought (not as comprehensive thought).

D3CK

[Urs]

I was actually at the official VST3 SDK launch at NAMM today.

I've seen you there!!!

Everyone I spoke to was highly annoyed. Especially because they not just announced a quarter of losses for us but also because they made a developer meeting into a marketing blurp for, yeah, for what? Damn there wasn't even any Steinberg developer attending. The free beer was nice though.

#---

Sorry I'm late for the party. Anyone volunteer to sum up? What's the general vibe?

[Ben [KVR]]

I'd be happy for KVR to get behind something like this with any resources we could provide (domain, hosting, forums, storage, wiki, cvs/svn, etc.).

Let me know if there is anything I can do to help.

[Angus_FX]

I've decided to set up a reflector list to discuss this and see if there really is scope for an alternative - Urs, Ben, anyone else, if you want to be added, mail me.

EDIT:- Just seen BenKVR's post above - going to arrange this with him

[nollock]

Why not go with JUCE?

Licensing problems, not langauge agnostic, it's just a wrapper round existing formats and not an API.