Yeah, I get that Angus. I think it actually TRIED, but failed. And of course, the way Steinberg treats the feedback process is a joke.Angus_FX wrote: The problem is that VST3 fulfils only one of those three criteria, namely that it deprecates VST2. It doesn't grow from the same root, and it's less mature, not more.
VST3 - known issues (Updated Jan 2019)
-
- KVRAF
- 6095 posts since 5 Jul, 2001 from Just about .... there
If you have to ask, you can't afford the answer
-
- KVRAF
- 6095 posts since 5 Jul, 2001 from Just about .... there
I apologies for butting in on Urs thread. But, I do appreciate his predicament and am grateful he is still planning on plugging along the VST3 route.
If you have to ask, you can't afford the answer
-
- KVRAF
- 4735 posts since 18 Jul, 2002 from London, UK
Yes, I agree. The Steinberg devs have (mostly) good intentions on the engineering front, even if there are some aspects of VST3 that I question at a philosophical level (as I've said before, my taste is for something closer to a peer-to-peer interconnect design, where plugin and host are broadly equal, than one where the host dictates too many aspects of plugin design & behaviour). More 19in rack than Eurorack, if you like.
On the community engagement front? Complete and utter fail.
On the community engagement front? Complete and utter fail.
This account is dormant, I am no longer employed by FXpansion / ROLI.
Find me on LinkedIn or elsewhere if you need to get in touch.
Find me on LinkedIn or elsewhere if you need to get in touch.
-
- u-he
- Topic Starter
- 28062 posts since 8 Aug, 2002 from Berlin
The should've mad ethe communication between plug-in and host synchronous too.
Host: Plugin Controller, tell me your number of parameters
VST3 Controller: Yeah, will do
VST3 Controller: Hey DSP Process, how many parameters have we got today?
… short break…
VST3 Processor: Yo Controller, we got 79 parameters
VST3 Controller: Dear host, I have the information you wanted. It's 79 parameters.
Host: Finally. Thanks.
Host: Plugin Controller, tell me your number of parameters
VST3 Controller: Yeah, will do
VST3 Controller: Hey DSP Process, how many parameters have we got today?
… short break…
VST3 Processor: Yo Controller, we got 79 parameters
VST3 Controller: Dear host, I have the information you wanted. It's 79 parameters.
Host: Finally. Thanks.
-
- KVRAF
- 3184 posts since 31 Dec, 2004 from People's Republic of Minnesota
If you're making audio software to be rich that's kind of a stupid plan. There are other ways that have a much higher success rates with regard to riches. Lol.chilly7 wrote:Oh i forgot this is yamaha. idiots, they care only about money and nothing else...SJ_Digriz wrote:Because Steinberg have stopped support of VST2.chilly7 wrote:So what is the point of making VST 3 if VST2 is good?
I am using only AU so sorry if i miss something...
-Sam
-
- KVRAF
- 13203 posts since 16 Feb, 2005 from Kingston, Jamaica
so Angus and Urs I am curious.
Have you brought up these issues to SB and they have listened politely and done nothing about it?
OR are they planning to fix it?
or they aren't even aware of these problems?
rsp
Have you brought up these issues to SB and they have listened politely and done nothing about it?
OR are they planning to fix it?
or they aren't even aware of these problems?
rsp
sound sculptist
-
- u-he
- Topic Starter
- 28062 posts since 8 Aug, 2002 from Berlin
I'm pretty sure they are aware of the problems.zvenx wrote:so Angus and Urs I am curious.
Have you brought up these issues to SB and they have listened politely and done nothing about it?
OR are they planning to fix it?
or they aren't even aware of these problems?
rsp
I don't think there's anything that can be done about them. It's a design issue, not a question of bugs that can be fixed.
(I think though Avid should set AAX free, less the codesign requirement… I like it a lot)
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
The problem lies buried deep in the overambitious design of VST3.
One of the intended "phenomenal" changes to VST2 was the strict separation between audio processing and controlling part. They are two independent objects in VST3(.0), and their communication is designed to be done through asynchronous messages sent between them. The messaging is performed by the host. This allows, in the grand scheme of things, niceties like running the processing on one machine and the editor on another.
In practice, with this asynchronous messaging scheme, they introduced an unmanageable nightmare, because anything that is remotely timing-dependent doesn't work reliably any more. Plus, they added a nice little "double-binding" in the SDK. If you look at the VST2 Wrapper, you'll notice that it effectively shortcuts the messaging process. It simply fuses the two components together and introduces a synchronous messaging scheme. This is, as a very nice example, totally different to how Cubase handles things - but relatively consistent with the model, since a VST2 PlugIn can only run on one machine anyway, so there's no need for an elaborate message passing mechanism.
Third part of the puzzle: as a host writer who wants to support VST3, you have to decide on your own scheme how to do it. There's no guidance except for the VST2Wrapper, which deliberately bypasses the problem. Guess what - each VST3-supporting host has its own way to deal with asynchronous message passing. Some of these may even make it impossible to fire a message and wait until the answer has arrived (just imagine they're passed as posted window messages), while others won't work asynchronously at all (my hosts, for example, copy the VST2Wrapper behaviour, since they can't split the processing and editing parts anyway) - if, as a PlugIn writer, you decide to "go by the rules", simply fire a message and return, waiting for the result to come in at a later time, you're screwed as it's already there as soon as the message firing has been completed. You need to be prepared for all these scenarios - and, unfortunately, some of them are mutually exclusive. The only chance to get out of this is to react differently on each host. Out of the frying pan, bang straight into the fire...
tl;dr - asynchronous messaging doesn't work reliably. Getting it to run in Cubase alone is a little nightmare, getting it to run in other hosts as well is a big nightmare.
That's why Steinberg added a simplified model where processing and controlling part are allowed to reside in one object, thereby removing the schizophrenic need for them to talk to each other. Of course, if you already invested a lot of time into creating a PlugIn using the separated model, it means quite a lot of work to switch back to the simplified model. You have my heartfelt sympathies, Urs
One of the intended "phenomenal" changes to VST2 was the strict separation between audio processing and controlling part. They are two independent objects in VST3(.0), and their communication is designed to be done through asynchronous messages sent between them. The messaging is performed by the host. This allows, in the grand scheme of things, niceties like running the processing on one machine and the editor on another.
In practice, with this asynchronous messaging scheme, they introduced an unmanageable nightmare, because anything that is remotely timing-dependent doesn't work reliably any more. Plus, they added a nice little "double-binding" in the SDK. If you look at the VST2 Wrapper, you'll notice that it effectively shortcuts the messaging process. It simply fuses the two components together and introduces a synchronous messaging scheme. This is, as a very nice example, totally different to how Cubase handles things - but relatively consistent with the model, since a VST2 PlugIn can only run on one machine anyway, so there's no need for an elaborate message passing mechanism.
Third part of the puzzle: as a host writer who wants to support VST3, you have to decide on your own scheme how to do it. There's no guidance except for the VST2Wrapper, which deliberately bypasses the problem. Guess what - each VST3-supporting host has its own way to deal with asynchronous message passing. Some of these may even make it impossible to fire a message and wait until the answer has arrived (just imagine they're passed as posted window messages), while others won't work asynchronously at all (my hosts, for example, copy the VST2Wrapper behaviour, since they can't split the processing and editing parts anyway) - if, as a PlugIn writer, you decide to "go by the rules", simply fire a message and return, waiting for the result to come in at a later time, you're screwed as it's already there as soon as the message firing has been completed. You need to be prepared for all these scenarios - and, unfortunately, some of them are mutually exclusive. The only chance to get out of this is to react differently on each host. Out of the frying pan, bang straight into the fire...
tl;dr - asynchronous messaging doesn't work reliably. Getting it to run in Cubase alone is a little nightmare, getting it to run in other hosts as well is a big nightmare.
That's why Steinberg added a simplified model where processing and controlling part are allowed to reside in one object, thereby removing the schizophrenic need for them to talk to each other. Of course, if you already invested a lot of time into creating a PlugIn using the separated model, it means quite a lot of work to switch back to the simplified model. You have my heartfelt sympathies, Urs
Last edited by arakula on Tue Dec 17, 2013 11:49 am, edited 1 time in total.
"Until you spread your wings, you'll have no idea how far you can walk." 
-
- KVRAF
- 14658 posts since 19 Oct, 2003 from Berlin, Germany
Urs, do your plugins have the infamous "Audio Forward Bug" in Wavelab with the VST3 version?
What's happening, is that the audio stream is only "slightly" to non-processed while rendering. In realtime, it is working.
So far I didn't run into this with SATIN, then again, SATIN is not my go to plugin for Wavelab. But I do know that Klanghelm, Slate Digital and Eiosis have this issue. For several months now - with no solution other than "use the VST2 version in Wavelab".
You can also read more about this here:
http://www.steinberg.net/forums/viewtop ... 89&t=48712
What's happening, is that the audio stream is only "slightly" to non-processed while rendering. In realtime, it is working.
So far I didn't run into this with SATIN, then again, SATIN is not my go to plugin for Wavelab. But I do know that Klanghelm, Slate Digital and Eiosis have this issue. For several months now - with no solution other than "use the VST2 version in Wavelab".
You can also read more about this here:
http://www.steinberg.net/forums/viewtop ... 89&t=48712
-
- u-he
- Topic Starter
- 28062 posts since 8 Aug, 2002 from Berlin
Thanks guys, it's comforting to know that we're not the only ones.
Hermann, I hadn't had the idea yet that some hosts return messages immediately, and thus before the request has returned. Not sure if it affects our implementation, but… what a bummer!
Hermann, I hadn't had the idea yet that some hosts return messages immediately, and thus before the request has returned. Not sure if it affects our implementation, but… what a bummer!
-
- KVRian
- 995 posts since 25 Apr, 2005
And yet Steinberg have still deprecated VST2 and made its SDK unavailable for download.
So presumably Steinberg either don't understand the problems, they just don't care or don't have the resources / ability to deliver a working plugin format.
None of which gives me confidence in the people controlling the spec of probably the most widely used audio plugin format. Obviously control is power and all that which Steinberg wouldn't want to give up but it is really not a good situation for the VST community to be in where one company has such absolute control over the spec.
So presumably Steinberg either don't understand the problems, they just don't care or don't have the resources / ability to deliver a working plugin format.
None of which gives me confidence in the people controlling the spec of probably the most widely used audio plugin format. Obviously control is power and all that which Steinberg wouldn't want to give up but it is really not a good situation for the VST community to be in where one company has such absolute control over the spec.
-
- u-he
- Topic Starter
- 28062 posts since 8 Aug, 2002 from Berlin
Well, I guess it simply backfires. Every plug-in dev will only ever support the "simplified VST3" - which essentially is just a slightly more complicated version of VST2. This whole thing weakens Steinberg's position.
Note that the VST2 SDK is included in the VST3 SDK. It just comes without the docs and demo projects. Those however can be legally obtained elsewhere.
Note that the VST2 SDK is included in the VST3 SDK. It just comes without the docs and demo projects. Those however can be legally obtained elsewhere.
-
- KVRAF
- 4735 posts since 18 Jul, 2002 from London, UK
A bit of all 3.. I wouldn't say they don't understand the problems, more that they don't see it as being a problem (or think the tradeoff is worthwhile).So presumably Steinberg either don't understand the problems, they just don't care or don't have the resources / ability to deliver a working plugin format.
They don't care, in as much as VST3 seemingly fits in with their long term objectives (whatever those may be), and as long as the burden of complexity is borne by someone else (whether that be plugin developers having to work with their brain-damaged architecture, or host developers having to write more complex code to support split-view plugins) so be it.
And they don't have the resources, Yamaha run a pretty tight ship & why would they divert developer time for the good of the community, when that community includes several of thier close competitors.
Urs, I agree re AAX - it's not perfect, but it's by far the least-worst of the current generation of APIs; it's even possible that Avid are the most well-intentioned major player with regard to the future of our industry (if they'd just kick those PACE snake-oil-vendors to the kerb permanently).
This account is dormant, I am no longer employed by FXpansion / ROLI.
Find me on LinkedIn or elsewhere if you need to get in touch.
Find me on LinkedIn or elsewhere if you need to get in touch.
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
It's perfectly legal and might also happen with truly asynchronous messages processed in different threads. You have to be prepared for that.Urs wrote:Hermann, I hadn't had the idea yet that some hosts return messages immediately, and thus before the request has returned. Not sure if it affects our implementation, but… what a bummer!
"Until you spread your wings, you'll have no idea how far you can walk."
-
- u-he
- Topic Starter
- 28062 posts since 8 Aug, 2002 from Berlin
The latest news…
We're taking VST3 out of the default installation options. The next update will have an optional VST3 install, for those who need to run their existing projects with VST3.
With just Sascha and me as the only developers at u-he currently we can not deal with VST3 now, nor within the next few months. There is no immediate fix for the constant crashes and erratic behaviour in a growing variety of hosts. We need to rewrite this thing and it'll take months of work and testing.
The good news is, we've hired more staff, we find bugs quicker and we'll soon have more developers around.
We're taking VST3 out of the default installation options. The next update will have an optional VST3 install, for those who need to run their existing projects with VST3.
With just Sascha and me as the only developers at u-he currently we can not deal with VST3 now, nor within the next few months. There is no immediate fix for the constant crashes and erratic behaviour in a growing variety of hosts. We need to rewrite this thing and it'll take months of work and testing.
The good news is, we've hired more staff, we find bugs quicker and we'll soon have more developers around.
