VST3 SDK could need some improvement...

[BlueprintInc]

IAudioProcessor has only 8 methods (excluding FUnknow). Even if you include IComponent with 11 methods (excluding FUnknow) it still be less than 28.

You're right. I was offhand. VST3 requires the following Interfaces on an audio processing plugin:

FUnknown (3 methods)
IAudioProcessor (8 methods)
IComponent (9 methods)
IPluginBase (2 methods)
IConnectionPoint (3 methods)

Which is 25 methods total to implement a VST3 audio processor.

Your MpPluginBase has 26 methods derived from at least 4 interfaces, MpBase already adds 7 more... What exactly is the point now?

I think you are illustrating the general hostility toward any attempt to make a new plugin standard.
Not that I'm blaming you, I think the attitude is very common. Software developers need to ship products, and we don't like to be confronted with a new learning curve without good reason. This is why we will not be seeing any alternative to the status quo.

So seeing your interface already is not that easy or small anymore, I think we agree that any "easy" alternative misses a bunch of already established functionality or is too general to fit the use cases. Sure, I think VST3, AAX & AU are bloated in some form, but I also see the reason why it is like that, may it be to support DAW or hardware specific functionality or to have an easy basic interface extensible to support functionality for all kind of plugins.

[Vokbuz]

I think you are illustrating the general hostility toward any attempt to make a new plugin standard.
Not that I'm blaming you, I think the attitude is very common.

Your post wasn't an attempt to make a new plugin standard. What you did is just wrote quite obvious small part but presented it as:

> An audio plugin would need only the following methods...

Do you feel the difference?

Software developers need to ship products, and we don't like to be confronted with a new learning curve without good reason. This is why I don't expect we will be seeing any alternative to the status quo.

Community plugin format has nothing to do with learning curve. You would need to learn that new format. Also community plugin format won't protect you from the need of relearning and rewriting. It can change as any other proprietary one.

Which is 25 methods total to implement a VST3 audio processor.

And these 25 methods still do much more than your plugin format that you comparing them with.

[gnjp]

Also community plugin format won't protect you from the need of relearning and rewriting. It can change as any other proprietary one.

I'd rather track the changes of 1 community format than 4 or 5 proprietary ones.

[karrikuh]

Like others, I'm very displeased with state of current plug-in standards and would welcome a truly free, cross-platform plug-in standard.

There was a proposal announced many years ago which to me seems pretty well designed:

https://free-audio.github.io/clap
https://github.com/free-audio/clap/
viewtopic.php?f=33&t=428482

Some things I especially like about it are:

• Written in plain C, thus maximally portable and language binding friendly
• The base spec is just a header file. Should be easy to integrate into existing plug-in frameworks
• Really straight forward overall design. Just by studying the header, I get a good idea how stuff is supposed to work on both host und plug-in side.
• Comes with all the features you expect, and lacks stuff no-one needs. Still allows extensions.

There are a few changes I would consider, such as:

• be able to dynamically change host sample rate. This has been also mentioned in the past by REAPER devs as a crucial shortcoming of LV2.
• Allow host to query plug-in info witout instantiating it, for faster scanning.

A spec alone isn't enough, though, so I think it would need a few things in order to have a realistic chance for adoption:

• a light-weight C++ support library for plug-in and host implementations
• example plug-ins: gain effect, simple monophonic synth
• cross-platform reference host implementation
• Support by plug-in frameworks (JUCE, IPlug2,...)
• a modern website

[Jeff McClintock]

There was a proposal announced many years ago which to me seems pretty well designed:

https://free-audio.github.io/clap

LV2(a plugin API) and other plugin APIs often provide a document specifying what features they support, compared to the GMPI (Generalized Music Plugin Interface) specification. GMPI is a good reference because it covers most of the main requirements captured from consultation with a wide range of developers.

It would be cool to see this for clap.

LV2 Achievement of GMPI Requirements
https://lv2plug.in/gmpi.html

SynthEdit Achievement of GMPI Requirements
http://synthedit.com/software-developme ... fications/

[adammonroe]

As a dev with 20 years of experience it took me one month to make the VST3 SDK work as expected. Time that could better be invested in updates or new features of the products.

It's been a few years since I looked at the VST3 SDK. From what I remember it looked like a confusing mess compared to VST 2.4 and I thought to myself "naaaaaah." Even just went ahead and hacked VST 2.4 to compile a 64-bit MAC version by dumping Carbon and using Cocoa because that seemed easier than adopting VST3 at the time! However, since Cubase 10 came out I am getting a lot of complaints from Cubase users about VST 2.4 and its Plugin Manager (I believe Steinberg is trying to force people into dropping VST2). Likely next year I will begrudgingly start compiling VST3 versions alongside recompiling code for Apple's ARM changes. It's probably going to end up being a whole year of accomplishing nothing but ports!

Classic example of "if it ain't broke, don't fix it."

[Angus_FX]

be able to dynamically change host sample rate. This has been also mentioned in the past by REAPER devs as a crucial shortcoming of LV2.

While the stream is running? Or just being able to update sample rate without tearing down the plug-in and re-instancing?

Allow host to query plug-in info witout instantiating it, for faster scanning.

Doesn't necessarily work as well as you might think. There are two costs to instancing a plug-in - module-load, and construction. Module-load is inherently heavy for some big PIs, but the only way around that is to have a metadata spec which has problems of its own.

Probably the best way to achieve fast scanning is to have a robust spec around cacheability, so that hosts only scan things that have actually changed (but dynamic shells/wrappers can mark themselves as not cacheable, for example).

[karrikuh]

be able to dynamically change host sample rate. This has been also mentioned in the past by REAPER devs as a crucial shortcoming of LV2.

While the stream is running? Or just being able to update sample rate without tearing down the plug-in and re-instancing?

The latter. The host would temporarily suspend processing before informing the plug-in about sample rate change. That's how it's done e.g. in VST2 (via effMainsChanged). The point is not requiring a plug-in to completely discard and re-load it's state which may be costly e.g. in the case of of a multi-GB sample library patch.

That being said, it might make sense to offer the possibility of dynamic samplerate change as an optional extension, because it often does put a considerable burden on the plug-in implementation and the speed gain over just re-instancing may not be worthwhile in many cases.

Allow host to query plug-in info witout instantiating it, for faster scanning.

Doesn't necessarily work as well as you might think. There are two costs to instancing a plug-in - module-load, and construction. Module-load is inherently heavy for some big PIs, but the only way around that is to have a metadata spec which has problems of its own.

Probably the best way to achieve fast scanning is to have a robust spec around cacheability, so that hosts only scan things that have actually changed (but dynamic shells/wrappers can mark themselves as not cacheable, for example).

Surely there are ways to further improve on this. I was mainly arguing that fast plug-in discovery should be considered as a goal and the current design seems to neglect it a bit.

[Vokbuz]

I'd rather track the changes of 1 community format than 4 or 5 proprietary ones.

Real situation will be: 4 or 5 proprietary ones + 1 community format. https://xkcd.com/927/

[syntonica]

I'd rather track the changes of 1 community format than 4 or 5 proprietary ones.

Real situation will be: 4 or 5 proprietary ones + 1 community format. https://xkcd.com/927/

The operative word here is "proprietary". Meaning "iron-fisted control".

[gnjp]

Real situation will be: 4 or 5 proprietary ones + 1 community format. https://xkcd.com/927/

will? lol, that's what we have..

[Vertion]

https://xkcd.com/1940/

[MackTuesday]

I'd be happy with just about anything that has a comprehensive definition. I don't mean tons of features, I mean well and thoroughly documented behavior, whatever features there happen to be. My only problem with VST is that different hosts work differently, exactly because VST isn't well defined.

[Vokbuz]

lol, that's what we have..

Yep, this is why people here "invent" new community format.

This is not what we have. There are plenty of community formats and none that is generally accepted. General acceptance of community format does not mean the death of proprietary formats.

[Vokbuz]

The operative word here is "proprietary". Meaning "iron-fisted control".

And again this has nothing to do with learning curve and changes to the format.