New Non Commercial Plugin Standard

[starise]

I think it's high time we ditched Steinberg. What say you? Let's put together an open source universal standard that is backwards compatible and works with all DAWs.

You can do this!

[frizzbee]

again? there already was a topic few weeks about it and it ended pretty quick.

[FigBug]

What's the plan to get hosts to support it? Without host support it's useless. LV2 hasn't had much success getting hosts.

Probably need to get JUCE to support it as well, so that you can get plugin developers onboard with 0 effort.

Chicken & Egg problem. How do you get plugins with no hosts? How do you get hosts to care when there are no plugins?

[imrae]

This energy should be directed towards LV2 adoption

[camsr]

What does non-commercial mean?
Why backwards compatible?
Works with "all DAWs", meaning it is platform-independent?

And why do all this to "ditch Steinberg"?

[camsr]

This energy should be directed towards LV2 adoption

What makes you say that? What are the strengths of LV2?

[camsr]

What's the plan to get hosts to support it? Without host support it's useless. LV2 hasn't had much success getting hosts.

Probably need to get JUCE to support it as well, so that you can get plugin developers onboard with 0 effort.

Why not start making a host to fulfill the criteria of a new plugin spec then?

Why wait for JUCE to do it when JUCE isn't developing it?

Chicken & Egg problem. How do you get plugins with no hosts? How do you get hosts to care when there are no plugins?

If nothing has been programmed then there is no problem, it simply doesn't exist.

[mladi]

I think it's high time we ditched Steinberg. What say you? Let's put together an open source universal standard that is backwards compatible and works with all DAWs.

You can do this!

[pekbro]

The format itself shouldn't really matter, having one organization with complete control over it, who's
main concern is their own vested interest, is probably not the best situation.

Yamaha will probably dump Steinberg sooner or later anyway and put the standard at risk.
*No worries though, Behringer will scoop them up right afterwards

[pekbro]

The same thing happened in the visual fx industry, only in this case Behringer will replace Autodesk.
The content creation industries ultimately cannot support too many big players, it's already happening
actually. Look at Sony, Roland etc. Give it another decade or so...

[imrae]

This energy should be directed towards LV2 adoption

What makes you say that? What are the strengths of LV2?

It already exists, it's open source and has a comparable feature set to VST. There are already some hosts that support it (Ardour, Audacity) and developers using it (e.g. Auburn Sounds).

Re: JUCE, they have made it quite clear that they will not be supporting LV2 until demand is stronger. They have not however raised any technical barriers to doing so https://github.com/juce-framework/JUCE/issues/123

So, whenever somebody raises the possibility of a new plugin format that will compete with VST on openness rather than on features... the obvious question is "why not LV2?"

[Eduur]

I would love an open standard. I followed the CAT thread intensively.
As a Delphi/Windows programmer (non-commercial) I only have a few needs:
1. Must be written in C, not C++. No COM or whatever.
2. Must be seperate from a UI kit.
3. The Code must work with Visual Studio, just like Reapers WDL, iPlug and Juce.
4. Please, no extra tools to compile needed stuff (like cmake, doxygen) unless it has a decent GUI and is understandable.

VST2 served all my needs, and so does FruityPlug (written in Delphi!).
VST3 was and is a PITA, but "we managed". Violates my wishes on 1 and 3 (a bit) .

So, where does LV2 stand for my wishes?
If Reaper was involved in an open standard, that could make the difference..

[rl]

Obviously: xkcd 927

[Guillaume Piolat]

I would love an open standard. I followed the CAT thread intensively.
As a Delphi/Windows programmer (non-commercial) I only have a few needs:
1. Must be written in C, not C++. No COM or whatever.

Indeed LV2 has a few number of well-chosen C callbacks.

Here is the LV2 reference host source: https://github.com/lv2/lilv/tree/master/src
Here is the LV2 spec, written in C too: https://github.com/lv2/lv2/tree/master/lv2/core

2. Must be seperate from a UI kit.

Yes.
LV2 support multiple window handle: X11 window handle, Qt handles, GTK handles, Cocoa handles... It is particularaly extensible.
And it's just giving the parent window handle, as it should.

3. The Code must work with Visual Studio, just like Reapers WDL, iPlug and Juce.

Probably the LV2 headers can work inside Visual Studio. For our use cases we had to translate them anyway, we don't use MSVC.

4. Please, no extra tools to compile needed stuff (like cmake, doxygen) unless it has a decent GUI and is understandable.

This part is not great for LV2, as it comes from the FOSS world with a few idiosyncrasies. But in the end it's a few C headers, it can be translated or rewritten very easily without tool change (it's the ABI that matters).

So, where does LV2 stand for my wishes?

Again, LV2 is the only existing format with the right licence and the right feature set, and something tells me you would like some of the design decisions inside it. It's definately not welcoming at first, and then you begin to appreciate the thought that went into it.

[EvilDragon]

LV2 has some inherent design problems that VST doesn't have problems with (for example complete complete destroy/create required on sample rate change, for one, which would create issues in a number of hosts).

Again, LV2 is the only existing format with the right licence and the right feature set

Errm, VST3 is also the right license, and also supports Linux... So no, LV2 is not the only one.

4. Please, no extra tools to compile needed stuff (like cmake, doxygen)

LOL, cmake comes with Visual Studio (even the free edition)... cmake is the least of your worries (and is actually a pretty nifty thing).