pouët.net

Steinberg didn't exactly make it easy to find the registration site for at least the last 5 years or so... It's not only the developers' fault.


That's only for MIDI events, not parameter automation. There is actually an undefined event type for parameter automation that would have allowed sample-accurate parameter automation in VST2, but the struct for this event time was never defined properly. All those great new VST3 features that Steinberg advertises could have been implemented easily in VST2.


Yes, it's possible, but it's ugly, implementation-wise.

What will happen to the BeOS support then? :(

Steinberg VST is written by Yvan Grabit.
Same guy who did the early OFFICIAL steinberg synth, with lacking normalization in the filters.

He didn´t even know a one pole.

That is how it feels to work with it aswell. Very little knowledge of how GUI works etc.

What happened. HTML became a standard. Windows took over. The same shit is expected from other parties? We were already ahead of this, on Amiga in 92.

And Linus had officially approved the Nerd label. Which really wasn´t how it was either.

Reduction to feeble idiocy.

And The Bible says Jesus turns water to wine, and you have a hundred drunkards. LSD makes you The Godh, and you have a thousand acidheads, and there is manna in the desert, and you have sect of blindly wandering opium clowns.

Push your start button boy. And appreciate windows, for not having decent thread priority ever, since its inception. There will be manna.

This seems to be the end also for Flowstone / Synthmaker ?
Or they will maybe rewrite the engine with 64bits export and AU... Who knows.

Go on...? (Just kidding. Don't.)

@bsp: what saga said. sample accurate midi is fine though, if 7bit (or 14 in case of pitch bend) are enough for you.
Usually, parameters are being smoothed to death, even in case of automation (you get a new value per buffer update at best, great, so behavior depends on buffer size too!).

Resizing can be implemented, but it will be extremely hacky and platform specific. There are hosts that like to put the vst ui inside their own ui containers, for example. This messes with the obvious ideas to implement it ;)

Ugliest hack I had to implement so far (but that's more of a windows problem) was overriding the host processes dpi scale in order to allow high res UIs to be used even if the host doesn't support it fully. For stuff like this you have to go down the "fetch HWND, do win32 stuff within nice #ifdefs"-road.

But I guess I should stop rambling about the shortcomings of VST now and write some audio code instead ;)

Ok one more thing: optional sidechain audio inputs...

VST2 already supports optional inputs? at least that is how our side-chain compressor works.

Sound a bit like LV2, except that the latter isn't VST2-compatible. But of course, no important players implement it, so you're stuck with VST2/3 anyway.

@djhoffman, yes. but you can't define semantics for those properly. actual behavior (or better "interpretation") depends on the daw. it's a pain in the ass.

By VST2 compatible I meant particularly source compatibility. Drop in freely licensed replacements of aeffectx.h etc and be free from proprietary bullshit feed.

jco: so you don't like that particular pain in the ass. Maybe it depends on the shape of your ass. Some people get a much bigger pain in the ass when a company dictates how they share their hobby projects, which I think is what this thread is about.

@Saga Music / @jco: that's the problem, it is not enough to include a kVstParameterType in an enum and a deltaFrames field in some event structure, people (plugins and hosts) have to actually implement them and apparently no one ever did.

The VST2 plugin format is not exactly pretty, and yzi is absolutely right, it's time for an open source replacement.
Since there are soooo many VST2 plugins out there, it would probably be a good idea to be backwards/binary compatible with VST2 but as you will all agree, there should also be some (well documented!!) extensions.

For example (off the top of my head)
- simplified MIDI-like events that support float parameters (this should probably be the core)
(I like MIDI but parsing (N)RPNs is not exactly fun or elegant)
- multi-device MIDI I/O
- idle hints (to skip processing calls when there are no active voices)

The question is: Would there be any legal ground for Steinberg to sue ? Can they copyright an enum or a simple structure ?
I don't think so but only an IT lawyer can tell.

And since cross platform plugin UIs are the main obstacle for many devs, a new format should include a standardized UI description language.
Similar to how hosts can already support plugins without own UIs but a little (a _little_) bit more complex.
It would be good enough for many plugins out there.
This should not be mandatory, though.

When I recently adapted VCV Rack as a VST2 (see here, I noticed that its UI is built on SVG.
I think it's a good approach (what's not so good is that they expose all the rack engine internals, including global vars, to the plugins but that's a different story)

Couple that with some a simple markup language that lets you place sliders / knobs / buttons etc on top of an SVG (or a blank panel), let the plugin report some meta info like "display this param as percent / integer / float within a given range", and plugins can let the host handle most of the hard UI work.

This would also make it possible to put effects and instruments into a virtual rack, like Reason does.
(one of the things I dislike most about VST plugins is that each one opens its own window, it drives me crazy!)

But don't ge me wrong: I don't want a bloated format, and at its core it should be just a header file and plugins should only be required to implement the bare minimum.

Both Saga Musix and I are currently working on VST hosts, so maybe we should get our heads together, design such a new plugin format, and implement it in our hosts (not using the same implementation, of course).

JCO, yzi, djH0ffman and maybe other plugin devs could be convinced to review the design / use the resulting SDK to port a plugin or two. I bet we could come up with something useful !

Oh boy have I got some bad news for you

Also,

@porocyon: I don't think it's appropriate to compare that Google vs Oracle situation to the VST2 dispute. Java is much more than just a couple of enums and simple structs, and I don't get why Google (they are loaded!) didn't just license it for their Android system. That may be an unpopular opinion but that's how I see it (besides, it's an ongoing case and there is no final verdict AFAIK)

The basic problem is that, even when you are morally and factually right, the side with the better lawyers may still win.

So, on second thought, let's ditch the VST2 binary compatibility.

The VST2 SDK has been around for so long that everyone and his dog has a copy of it. No real need to replicate it.

Which brings us to your image (which I _knew_ would be posted sooner or later :D).

We could stick our heads in the sand and come to the conclusion that it's all futile and things won't improve, ever, and that we just have to suck up to whatever company dictates as a (poorly documented) plugin standard, which might later be revoked, leaving everyone who built on it stranded.

Or we could take the initiative and devise something better that comes with no strings attached.

I think some of the people here are up to that task.

And to be honest: I'd rather see people with a pragmatic background work on this than a committee that ends up with a bloated, does-it-all, hard to implement spec (the "homer-mobile").

To further elaborate: The key here is to create a format that is simple, properly documented (unlike the VST SDKs), and does not change every couple of months (like the Linux kernel internals, for example).

How exactly is yet another plugin standard that noone uses going to solve anything? It's not like there are no alternatives, it's more like noone uses them because they have no support from major vendors, and guess who is not going to be interested in in dropping VST support.

!!! I love how you just casually dropped this in here :) 'i was looking at putting this into a buzz machine (yes, i know, an even more out of date standard, sue me) but 100 other projects distracted me. Can't wait to try this in a daw!

I think the dispute boiled down to 9 lines of range checking code, not all of Java. In other words, size doesn't matter when it comes to copyright infringement. However, the dispute is still different, since the 9 lines were allegedly copied, which isn't the same as clean-room reverse engineering.

Also, what Saga said. There are already open source plugin APIs available that nobody uses.

@Saga Musix: the major vendors could not care less about this. It's the little fish like us who have to suffer the consequences.
Explain to me how people will be able to build your (or my) VST host in the future once Steinberg has erased all legally available VST2 SDKs from the face of the earth.

We can either
- drop VST2 support and move to VST3
- or make the app binary only
- or point people to some dark corners of the internet where they still might find now-illegal copies of the header files
- or even risk a confrontation with Steinberg and redistribute the SDK ourselves
- or we could try to establish a truly free alternative which might eventually be picked up by other plugin devs (we don't know the future, do we).

For all I know, devs are less than excited about VST3.

@absence: please point me to the open source projects that are viable alternatives to VST2.
The ones I found are either obsolete / superseded, or are similar to VST3 in terms of complexity.

Last but not least, while the LGPL license is perfectly compatible with closed source apps (as long as you just use the header file), it scares off devs who don't understand the legalese, or feel like they are joining a cult by simply building upon such a header (which has no factual reason and is just false believe in the first place -- but you cannot argue with that)

I'm a free open source advocate in general but for something so basic as a plugin format header, I'd definitely use a plain and simple to understand license like MIT instead.

@mantratronic: yeah, polyphonic modular patches are fun! (which brings me back to the plugin format topic..why the heck does each modular host use its own plugin format!)

What exactly are you arguing about now? You proposed to define a new plugin standard that will be awesome and used by everyone. There are already multiple competing free standards but nobody uses them. Adding yet another standard to that will not solve your problem. You can go and write LADSPA plugins (which have been around for a long time) but hardly anyone will be able to use them. Just by defining yet another competitor doesn't give you a "viable alternative" to VST2.

You are pointing me to LADSPA. What part of "simple" did not you understand ?

A header file that looks like the instructions for a space shuttle take off sequence is an instant turn off (but your mileage may vary).

It also uses a GNU license (again, instant turn off for some closed source folks).

Are you still wondering why hardly anyone uses it ?

They key to this is simplicity. Any plugin format that does not come with a simple "amp" example plugin that can be implemented in a few lines of code is an instant fail, unless you are shooting for the moon (literally).

I think you're missing the point. The reason people use VST is becase it's the de facto standard for commercial audio software on Windows. You can certainly define a better API, but you'll have a hard time convincing developers to use it when the resulting plugins can't be loaded into Cubase or whatever.

maybe you should talk to justin frankel (the reaper main dev) how he thinks about implementing a new plugin standard. if anyone of the bigger daw-devs can be convinced its a good idea, its him (still doubt it, tho).

Reaper isn't "bigger".