Steinberg: No more VST2 Development

[kbl]

Whenever you think about XML, Jason or whatever, please ensure, that the resulting plugins should be able to be as easily installed as by now under the current vst2 approach and a portable install should be possible .

Vst2 was successful against directx mostly because you could simply place a dll wherever you wanted and that was it, deleting the file would definitely remove the plugin from the system. Directx needed an installer, and an uninstaller.

So, in most cases, it should stay like that, only battleships should require more .





Vst3 has already lost that simplicity ...

[obiwanjacobi]

@Urs: I always thought the thinking behind this design was that the GUI is less important than the DSP (rather a little late on the GUI than a hickup in the audio). So the information that the GUI requires is retrieved asynchronously to make sure it isn't blocking the DSP..?
The host implements the async-mechanism so that is no worry for the plugin...?

The description you give of how/where the parameters live (in the DSP object) make sense to me, I would do it the same. I just cannot envision why you would need these hacks... (disclaimer: studied VST3 design, never built anything with it)

[Urs]

In VST3 the main object that communicates with the host is the controller. The controller tells the host about the number of parameters, their names and so on.

The dsp object on the other hand is just some lightweight container that does the processing.

In theory that's good, but in practice it's the other way round: The DSP object contains all information and structure, the GUI object queries that, happily in an asynchronous way.

Unfortunately in VST3 the host queries the controller object about information, not the dsp object. And due to the asynchronous messaging, the controller object can't retrieve that information on the fly.

My employee who did the port had huge problems. I was puzzled about that until I looked into this myself, and I still have trouble believing it.

[AdmiralQuality]

Well then please explain this to Arne because as you can see from the quote above, he's under the impression everything is slick as snot. (Do they even USE their own SDK?)

[obiwanjacobi]

Maybe not the SDK but they use VST3. That means they are also experiencing the controller problems etc.

Or the query for custom interfaces... No, they wouldn't, would they?

[hibrasil]

of course Steinberg are using the SDK. VST3/VSTGUI SDK releases have correlated with new features and new products that they offer (for example nanologue came out at VST3/VSTGUI became able to do iOS).

Unlike, Urs and others, their latest products start life as VST3 plugins - they are not trying to make a VST3 version of an existing product or adapt their existing codebase.

[AdmiralQuality]

of course Steinberg are using the SDK. VST3/VSTGUI SDK releases have correlated with new features and new products that they offer (for example nanologue came out at VST3/VSTGUI became able to do iOS).

Unlike, Urs and others, their latest products start life as VST3 plugins - they are not trying to make a VST3 version of an existing product or adapt their existing codebase.

As it's a complete ground-up re-write to support VST3, the fact that Urs has been porting existing code should have nothing at all to do with it. Read what he's telling you.

[lkjb]

As it's a complete ground-up re-write to support VST3

Of course, this is wrong. Only the interface stuff needs to be adapted and even this will most probably only be done once for all plugins.
You don't really think u-he or any other developer that supports VST3 writes every plugin twice for VST3? At least I hope this isn't the case.

[AdmiralQuality]

As it's a complete ground-up re-write to support VST3

Of course, this is wrong. Only the interface stuff needs to be adapted and even this will most probably only be done once for all plugins.
You don't really think u-he or any other developer that supports VST3 writes every plugin twice for VST3? At least I hope this isn't the case.

The "interface stuff" is 95% of a plug-in. Yes, obviously the process code stays much the same. But nobody's complaining about that.

And yes, that's what Urs has said he's doing as the VST3.5 VST2.4 wrapper doesn't work as advertised. (Correct me if I'm wrong please, Urs. Not meaning to speak for you.)

[Urs]

AQ, that's correct

We maintain a very simple internal interface to our framework that supports full separation of UI and DSP. It works very well with AU and AAX, without any shared pointer or memory between the two parts.

However, our framework was built with the assumption that the host retrieves plug-in information from the DSP part, where quite naturally information about structure and state reside. I've explained this a dozen of times with obvious examples

Unfortunately VST3 assumes that parameter information is stored in the GUI part. That IMHO is a flawed design when paired with asynchronous communication. As an example, both AU and AAX forgo the burden of asynchronous communication for non-realtime information - they'll return Properties immediately, while Parameters run asynchronously. That is, we can happily live with delayed parameter changes and automation messages, but we can't live with delayed getNumParameters() or getParameterName() - or our own getPlugInName, getNumInputs, getCurrentPresetDirectory fwiw.

Our plug-in framework is too object oriented for this, the DSP part is strictly capsuled away from the UI. We do not maintain any olden days global header file with central parameter lists, preset lists, module lists and so on. Our plug-ins build all of these during runtime, which is how we stuff a bunch of them into a single binary. It's an object oriented approach.

So yes, we have a true VST3 implementation that just doesn't work reliably after workaround for a workaround for a workaround.

To fuel this up a bit more, in AU we can even have the UI and the DSP in separate binaries. A UI binary compiled in 2003 would still provide a usable interface for Zebra AU, no matter how many parameters were added in 10 years. That's because quite logically, all information is accessed from teh DSP part. The UI binary can exist without any notion of the properties of the DSP part. The UI can query those parameters, preset names and so on, and it can set itself up. As long as we somewhere have an XML file for the UI layout, it'll all work.

Of course, we could for each plug-in maintain an extra XML file that's created by the DSP part and that the VST3 UI part could read, and it could base its information on that. We can also - as we do - open a dummy instance of the dsp part and query things from there. It sometimes crashes, but I think we have it under control now.

However, we store a lot of stuff per instance. That is, we distinguish between parameters that are saved with project as opposed to parameters saved with preset. In VST3 we can not access those "in time", e.g. we can not retrieve the current preset name, the current preset directory, what UI panes had last been opened, which parameters have been locked, which group a Satin has been assigned to and so on. Those are exactly the parts where our VST3s display information sluggishly.

In VST3 we would be required to support "GUI states". That is, a plug-in has two getChunk() preset retrieval locations. That may seem logical and consequent, but it's odd among plug-in formats. It brings unnecessary complexity to the table. Because everyone who supports more than VST3 has that functionality merged into a single place already.

All because VST3 requires us to handle messages asynchronously. This would be justified if it was a requirement for what it's meant for. However, in 2004 two Apple engineers debugged Logic Nodes with Zebra and Filterscape at my place in Berlin (those were the times...). Within an hour we had Logic run on one machine and Zebra on another - despite non-asynchronous messaging over 100MBit ethernet in 2004. So, hmmm, I can't really see the need for asynchronous messaging in 2014.

[mahaya]

We maintain a very simple internal interface to our framework that supports full separation of UI and DSP. It works very well with AU and AAX, without any shared pointer or memory between the two parts.

Can you elaborate on how your GUI communicates with the DSP?

Unfortunately VST3 assumes that parameter information is stored in the GUI part.

The parameter information is stored in the EditController which is part of the SingleComponentEffect, not the EditView (GUI). Only when not using the SingleComponentEffect, DSP and controller are separated (EditController has no direct knowledge of IAudioProcessor) and communication needs to be done asynchronically. Please correct me if I'm missing something here.

[arakula]

That's precisely the point - Urs switched to CSingleComponentEffect to get a manageable implementation that doesn't require keeping two copies of each parameter with the syncing nightmare.

[Urs]

That's precisely the point - Urs switched to CSingleComponentEffect to get a manageable implementation that doesn't require keeping two copies of each parameter with the syncing nightmare.

Yes, that's the plan. We still have "proper VST3", but we're going to cut it down to that SingleComponentEffect.

[hibrasil]

My point still stands that if you start a new project as a distributable VST3 and do things in the way Steinberg want you to (however wrong you think it might be), it should work - I guess it works for them. I haven't used their VST3 plugins extensively but if they do have major problems related to these distributed/asynchronous issues then i feel very sorry for their tech support team.

So far things are working ok for me with distributable VST3 (current version of IPlug uses SingleComponentEffect but i'm working on a new version that is distributed). When you start using the wrappers it gets complicated, especially if you want to have a preset system that works across formats, and tells the host about the preset list. The way that state is stored/recalled in multiple places is pretty horrible.

[Urs]

It does not matter how one twists things back and forth, distributable VST3 requires redundant storage of information and that's an anti pattern in my books. It IMHO leads to code that is hard to maintain and prone to bugs.

That said, asynchronous messaging and being distributable isn't much of a requirement these days, so the availability of the SingleComponentEffect fixes the issue for the time being