Well this is a kick in the nuts: VST2 plug-ins

[george]

But, why not to take a LV2? Reaper adopted it in recent builds not for Linux only.

JUCE framework still doesn't officially support LV2.

[Kott]

But, why not to take a LV2? Reaper adopted it in recent builds not for Linux only.

JUCE framework still doesn't officially support LV2.

Yes.
Do You need the official support? Pianoteq builds LV2 versions of their instruments (though they didn't publish their changes in JUCE). And you can do that so using https://github.com/DISTRHO/JUCE/
I have LV2 builds of your OB-Xd and OPL, are You interested?

[george]

Do You need the official support? Pianoteq builds LV2 versions of their instruments (though they didn't publish their changes in JUCE). And you can do that so using https://github.com/DISTRHO/JUCE/
I have LV2 builds of your OB-Xd and OPL, are You interested?

I'd prefer the official and in-house way thanks for the offer

[Kott]

I'd prefer the official and in-house way thanks for the offer

Stalemate situation. JUCE won't add LV2 until Devs asks them, Devs won't consider LV2 until JUCE implement it.
Someone has to step first.

IIRC. There was PR with LV2 support but JUCE's team refused it with some reasonable obligations (for that time), who will support it in our team?

[Kott]

I must mention that JUCE fork support building LV2 plugins only.
Hosting is possible https://github.com/lvtk/jlv2/ and works, but it still unstable yet.

[george]

Stalemate situation. JUCE won't add LV2 until Devs asks them, Devs won't consider LV2 until JUCE implement it.
Someone has to step first.

Perhaps LV2 isn’t ready for prime time.

[Kott]

Perhaps LV2 isn’t ready for prime time.

I don't think so. Not ready in what terms? It's stable and very documented. Maybe it's not the best in the world
And I think that lack of popularity just because no one promotes it in commercial plugins world.

IMHO there is a corporation's phobia hovers
"If the standard is not owned, then we cannot blame anyone if something goes wrong."

[george]

Not ready in what terms?

Low adoption rate and support from big companies.

I’d go the route suggested by Markus with VST2.

[Urs]

Crazy.

I guess the time has come for someone to publish a non-proprietary plug-in format and SDK that is compatible with the VST2 standard. If someone wishes to do that, I'll be happy to share some thoughts.

[imrae]

The Vestige situation suggests that some legal threats could still be expected?

Maybe the recent Android/Java ruling is helpful here, but I can't see a small player taking the risk.

[syntonica]

What's funny is that I always thought there should be ISO standards for software, from OSes on down with a certain amount of commonality within data structures, providing a basic laundry list of what should be implemented, at a minimum.

Are you familiar with the story of OOXML? https://en.m.wikipedia.org/wiki/Office_Open_XML An absurdly bloated standard that MS rammed through the standards orgs and couldn't even implement themselves...

I've never seen it, per se, but being based on XML tells me that it's 1) bloated and 2) most likely, done completely wrong as 99%+ of programmers don't know how to write XML properly. Whenever I see XML used as a format, I run the other way.

[arkmabat]

Crazy.

I guess the time has come for someone to publish a non-proprietary plug-in format and SDK that is compatible with the VST2 standard. If someone wishes to do that, I'll be happy to share some thoughts.

Yes. The DOSBOX of the audio world. Would be wonderful. VeSTige and others exist so this shouldn't be too hard unofficially. DAWs could just give an option to load in VeSTige support, like how MP3/LAME exporting was before the patent expired.

[arkmabat]

Honestly, I'm kind of excited to see VST die. LV2 or something rising up.

DAWs which already support it include:

Reaper
Audacity
Ardour

[Richard_Synapse]

I'm afraid a new format won't work unless the old one is dropped, or not introduced in the first place. Logic, ProTools or Reason (before VST2) are good examples for this.

Richard

[Urs]

I always wonder, why not make a new plug-in format "API-less"? What I mean is, the format could be a single header file that contains a dispatcher and variadic functions where all semantics (opcode numbers, function arguments and types, e.g. bytesize of plug-in identifier) are defined in a configuration file that resides in a location relative to the binary, e.g. the root directory of the plug-in binary/bundle. This way the code is free of any 3rd party copyrights and can come with, say, MIT license or something. The actual specific API(s) are defined in text files that users extend to. This way a new plug-in format can start out as LV2, but easily be extended to compatibility with other formats by editing text files.