Steinberg: No more VST2 Development

[JCJR]

And all we wanted was a simple buffer to fill and the means to attach to a host.
Pathetic.

... I've spent most of the last 18months figuring out APIs, OS changes (note - /not/ 'upgrades'), and config files rather than actual programming.

The price which must be paid for progress!

[Jeff McClintock]

If fact it could just start life as a plugin wrapper SDK, once it's up and running, stable, and has all the wrappers, then you can add the new plugin format. By then you'd have a good idea of everything that would be needed to keep the new plugin format able to easily wrap existing formats.

Well, you could put the plugin and the wrapper in the same DLL (or .so or whatever you have on other platforms).

Really, it's not like there are any real technical reasons that you couldn't start publishing those today. Just draft and API and go ahead.

This is the *only* way an independent plugin API can solve the 'chicken and egg' problem and bootstrap itself into popularity, by providing extensive wrappers for the other formats, and including dual entry-points (one dll supporting two APIs).
Like an open-source JUICE, it would make developers lives easier even without any host support (at first) for the new API. Very pragmatic.

[mystran]

If fact it could just start life as a plugin wrapper SDK, once it's up and running, stable, and has all the wrappers, then you can add the new plugin format. By then you'd have a good idea of everything that would be needed to keep the new plugin format able to easily wrap existing formats.

Well, you could put the plugin and the wrapper in the same DLL (or .so or whatever you have on other platforms).

Really, it's not like there are any real technical reasons that you couldn't start publishing those today. Just draft and API and go ahead.

This is the *only* way an independent plugin API can solve the 'chicken and egg' problem and bootstrap itself into popularity, by providing extensive wrappers for the other formats, and including dual entry-points (one dll supporting two APIs).
Like an open-source JUICE, it would make developers lives easier even without any host support (at first) for the new API. Very pragmatic.

Also.. as a tip I'd put the basic SDK required to support the API under a MIT-type license or something even less restrictive; the last thing you want is an "open" API where license restrictions cause additional head-aches (even LGPL type license a total pain to deal with in plugins, where you usually want a self-contained static link of everything [edit: and that's the primary reason I don't have interest in touching LADSPA with a stick, even if Linux support would be cool; I doubt that anyone really cares what I think, but my point is, I'm probably not the only one]). If you want to wrap into more fully featured SDKs with more restrictive terms, that should be a separate convenience feature.

[DaveHoskins]

It appears that a 'simple' vision is no longer applicable.
As these corporations fight for space, the creative 'third party's' of the music plug-in scene appear misguided, but it isn't so. We REALLY WANT to add value to the host software, whoever they are, but it appears they want otherwise.
An extreme view, probably, but one that seems more relevant as time passes.

[Caco]

It appears that a 'simple' vision is no longer applicable.
As these corporations fight for space, the creative 'third party's' of the music plug-in scene appear misguided, but it isn't so. We REALLY WANT to add value to the host software, whoever they are, but it appears they want otherwise.
An extreme view, probably, but one that seems more relevant as time passes.

It's not necessarily that they don't want you adding value, it's just that since Apple's success with their App Store many company's priorities are focussed on grabbing power and taking control of their own ecosystems. Sadly, the companies are often less bothered about the content within the ecosystem itself as long as they can be the ones who control it.

VST3 was a step in this direction by Steinberg. VST2 was so ubiquitous so that Steinberg had relatively little influence over but now it is gone and VST3 allows them to flex their muscle a bit more and have greater control.

Looking to the future, at what point will you have to sell VSTs exclusively through a Steinberg app store? VST4? VST5? I would be amazed if the idea had not been discussed by Steinberg / Yamaha at some point.

As it stands, Steinberg control the VST SDK and they control its future (and that of many 3rd party developers) unless a rival, open format is developed that is successful. It may be a lot of work / hassle to organise but it is surely in the long-term interests of 3rd party plugin developers and non-Steinberg hosts to try and take back some control before it's too late.

Steinberg don't care about you or 3rd party plugins, they are a corporation and so care about profit and control of the market.

[JCJR]

Just thinking out loud--

Would it be feasible to develop a "stupid simple to implement" plugin api, which would also be "stupid simple" to wrap? With a set of open-source "automatic wrapper programs"?

Would the "stupid simpleness" of the api also make it "stupid simple" to wrap, or might that make it more difficult to wrap?

Perhaps the version 1 of the stupid simple API would be only for faceless plugins, with no property pages? A wrapper program for instance for DirectX (if there would be any modern need for a DirectX wrapper in 2013) would have to auto-generate a generic property page editor, because most DirectX plugins expect property pages for the GUI. But the minimum AU or VST wrapper could optionally present its own auto-generated property pages, or merely present themselves to the host as faceless plugins?

And then a higher level version 2 of the stupid simple API could get into the custom property-page-window can of worms.

Ideally the stupid simple API would be as agnostic as possible on OS and language and compiler.

As best I recall, the long-gone mac 68K Premiere plugin api was pretty stupid-simple, though maybe it could have been simplified further. It was drafted as a non-real-time format, but it WAS possible to use that api to host real-time processing.

Maybe I'm remembering wrong, don't have time to look it up ATM, but for instance doesn't Audacity have some kind of plugin API? I never looked at the API, but perhaps if the open source hosts don't have plugin api's that are "correctly formed" for easy wrapping, then maybe the plugin api could be improved for wrappability?

If the api was simple enough to keep me from going crazy implementing it, I'd be real likely to add direct support for it in the hosts I help maintain. It would have to be simple enough to justify the programming time. I hate open-ended "science projects" implementing complicated API's.

[DaveHoskins]

I agree with all of that apart from the phrase 'stupidly simple.'
If I wanted to hammer a nail in I would use a hammer, I wouldn't look at the hammer and say, "what this thing needs is a motor, inter-changeable heads and a huge amount of handles and colours." It's just a hammer, we need stop to making it bloated and 'stupidly complex.' It should be a simple tool that does it's job well.
But that's just semantics I guess.

[Jeff McClintock]

Also.. as a tip I'd put the basic SDK required to support the API under a MIT-type license or something even less restrictive; the last thing you want is an "open" API where license restrictions cause additional head-aches.

Absolutely. It's zero use if it can't link to commercial APIs.

What someone needs to do is start with a fundamental exercise:
Create a plugin with wrappers for two significant standards on two OS's, for example a plugin that can be built for either VST or AU, on Windows or on OSX.
The plugin code should be identical in all cases, only the underlying wrappers should differ, in a transparent manner.
My definition of a 'good' framework, is one requiring the least code from the plugin coder. (loot at the VST3 gain example for an absolute abomination. pages and PAGES of code to make a gain plugin. A stunning violation of the 'keep it simple' principal).
Good demonstration plugins would be a gain plugin with one parameter (to represent effects), and later a simple synth (to represent instruments).
You could ignore GUIs at first, but maybe graft VSTGUI on a later point.

[Jeff McClintock]

The VST2 Gain example has 139 lines of code. The VST3 gain example is over 700 lines of code. That's an illustration of the poor usability of the SDK, because the SDK should provide sensible default implementations of all non-essential features. It's should not be such an effort to make a simple gain plugin.
GMPI for example provides the same functionality in 38 lines of code and 16 lines of XML. This includes all the advanced stuff like sample-accurate automation, silence-detection and optimisation etc.

REGISTER_PLUGIN( AGain, L"Gain" );

AGain::AGain( IMpUnknown* host ) : MpBase2( host )
{
// Register pins.
initializePin( 0, input1_ );
initializePin( 1, input2_ );
initializePin( 2, output1_ );
initializePin( 3, output2_ );
initializePin( 4, gain_ );
}

void AGain::onSetPins(void)
{
// Choose which function is used to process audio.
SET_PROCESS2( &AGain::subProcess );
}

void AGain::subProcess( int sampleFrames )
{
// get parameter value.
float gain = gain_;

// get pointers to in/output buffers.
float* input1 = getBuffer(input1_);
float* input2 = getBuffer(input2_);
float* output1 = getBuffer(output1_);
float* output2 = getBuffer(output2_);

// Apply audio processing.
while( --sampleFrames >= 0 )
{
*output1++ = (*input1++) * gain;
*output2++ = (*input2++) * gain;
}
}

[Jeff McClintock]

A very rough metric of Audio plugin SDK usability.

This shows a rough count of lines-of-code required to make a simple gain plugin in each format. Don't read too much into it, I'm sure other factors are important, but it's a useful metric.

Code: Select all

SDK    .cpp   .h  XML-etc  Total
VST2   128    39             167
VST3   757    92             849
GMPI    38    21     16       75
LV2           40     50       90
JUCE   232    74             306

[hibrasil]

Code: Select all

SDK    .cpp   .h  XML-etc  Total 
IPLUG   84    21            105 

including GUI

EDIT ... actually the resource.h file bumps it up to about 200 in total

[mystran]

I think comparing full toolkits and plugin APIs is apples and oranges though, because the more decisions you make at toolkit level, the shorter you can make the plugin code, but that's not necessarily a good plan for a standard API.

When it comes to an API, I don't think it's that important how many lines of code (within reason) it takes to wrap around it, as long as it's designed such that you can wrap around it once and then forget that it exists. That's why we use toolkits and frameworks, whether they are well-known or private. I think the problem mostly starts when an API tries to also be a toolkit, and you end with a huge mess trying to get through the high-level garbage and down to the core (where the actually functionality that you actually want is hidden).

What I'm trying to say: in toolkits you should make choices for "best practices" and try to make everything easy for the user. In an API you mostly want to do the opposite and try to provide clean functionality in a general way, trying to make everything easy for the toolkits. In my experience, often the "easiest to use" APIs are also some of the worst to wrap around, specifically because they make too many decisions on wrong level of abstraction.

Whether we need more toolkits is one thing, but another API might be a nice thing to have, though I wonder.. is there some technical objections against GMPI? Or is it just another standard that nobody bothered with? On face-value it doesn't seem significantly worse than what we have currently (and could probably reasonably co-exist in a VST plugin, without silly amounts of wrapper logic).

[sonigen]

is there some technical objections against GMPI?

I'd object to XML, I think XML is a bloated pile of verbose crap.

But my objection is more fundamental than that. An API should not require anything that is not really necessary. The interface should be simple types as much as possible, and the SDK should be self contained. It shouldn't need anyone to go find an XML library, or a whatever library before they can use it.

Like Angus said earlier in the thread, an API should not be intrusive, it should not force anything on us it absolutely doesn't need to.

I'm not 100% sure this is accurate since I only quickly glanced at Jeffs SDK but it looks like it's all C++. That the API is tied to C++ interfaces/classes. This is unacceptable to me, it should be plain C with C++ as an overlay. You make the API from C++ you limit future options, and you make life harder for people who are not using C++.

[JCJR]

I'm very ignorant but XML might be "as good as it gets" platform-agnostic way to substitute for the various resource files of yesteryear. Unless there is some other better way to get it done.

I don't really have a language preference. At one time was very fond of C/C++ and wouldn't mind using it again. But the folks I work with over the years, have massive heaps of working pascal code, which would take man-years to translate, and most likely would never be done EVER.

So an API at least accessible to pascal, hopefully EASY to access via pascal, would be necessary for me to easily adopt. When I eventually get too stupid to program and retire, then the language doesn't matter, but it currently matters.

Also, it probably would make various folks happy to "easily" interface with java, basic, objective-c, C#, whatever. People in my situation, trapped in a language by the weight of man-years legacy code.

[AdmiralQuality]

I think we already have this interface everyone is looking for. It's VST 2.4. As long as we all keep using it we'll be fine. And seeing as how there's still a legitimate method of downloading it (as part of the VST 3.6 SDK) then I don't see much of an issue at this time.

I'll save any further vitriol (I have a special gland for that) for if/when they stop offering the 2.4 SDK download entirely, making it impossible to source legitimately. Assuming that they don't otherwise release it for public use, which would be a laudable and much welcomed gesture (for a change).