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

[melomood]

nah That couldn't be the only reason

[Dasheesh]

its my understanding that vst3 does not handle midi as well. i'm not an expert on all the specifics, but some things just don't work in vst3 like vst2. one of you bright young minds should create a new standard and cut them off imo.

[arkmabat]

its my understanding that vst3 does not handle midi as well. i'm not an expert on all the specifics, but some things just don't work in vst3 like vst2. one of you bright young minds should create a new standard and cut them off imo.

Sadly, even Image Line and Reason tried, but they didn't catch on. It's the Windows XP problem all over again. Too many people use it to switch to a more reasonable alternative.

[syntonica]

its my understanding that vst3 does not handle midi as well. i'm not an expert on all the specifics, but some things just don't work in vst3 like vst2. one of you bright young minds should create a new standard and cut them off imo.

Sadly, even Image Line and Reason tried, but they didn't catch on. It's the Windows XP problem all over again. Too many people use it to switch to a more reasonable alternative.

I believe both were wholly proprietary, which is why they never gained any traction. Same with MAS, AAX, AU, etc. We just need a slight variant on VST 2 that is unencumbered by any licensing issues whatsoever. Basically, a Do Whatever You Want with it type license, but copyright and development are still controlled by the community.

My VST 2 header is currently single-file, under 1000 lines. C-based with the usual C++ candy wrappers, but wrappers for any other language are simple and straightforward. Frankly, anything more than that is just over-engineering. VST 3 still sits on my pile of things, next to AU2/3, that I need to learn, but it's so utterly overly-complicated, I can't even get started.

Steinberg created a monster (a good type) in VST 2 and in trying to kill it, it's created an even worse one in VST 3. I'm not even sure what benefit I get with VST 3. 2 gives me sample-accurate audio and MIDI with the ability to pass both through the chain. What more do I need?!?

[Music Engineer]

We just need a slight variant on VST 2 that is unencumbered by any licensing issues whatsoever. Basically, a Do Whatever You Want with it type license, but copyright and development are still controlled by the community.

well - we already have a pretty solid proposal from mystran:

viewtopic.php?p=7826063#p7826063

it may just need a couple of refinements - and then adoption. if this catches on, the world (of audio software) would be a better place. and then there's also LV2 which has no licensing issues but is quite heavyweight. i'd actually prefer a simpler and more lightweight solution like mystran's. a single header file with less than 1000 lines of code should do - why make things so overly complicated? this opi (or however it will be named in the end*) has no frills, no nonsense, no headache, no hoops to jump through. less is more.

more about it:
viewtopic.php?f=33&t=548620
viewtopic.php?f=33&t=549009
viewtopic.php?f=33&t=550537

(*) i think "open plugin interface" is a bit too general term - it should hint somewhere that we are talking specifically about audio plugins here...maybe oapi? ...although "cat" sounds actually quite catchy

[syntonica]

I've seen it. We just need some heavy hitters to get on board to support it. We just won't see it from Apple or Steinberg or Digidesign or any other entity fully invested in perpetuating their own technology.

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. This essentially rewards good, creative programmers who can implement these standards through good design. But, here we are, 40+ years later, with at least 3 major operating systems, with hundreds of variants and small players, all without any interoperability whatsoever. We get unnecessary (should never have been granted) software patents complete with patent trolls, highly proprietary formats that are desperately designed to lock users in, all handled by the types of people who couldn't even program Hunt the Wumpus in BASIC.

Programmers of the world UNITE and seize the IDEs of production!

[codec_spurt]

fu

[zzz00m]

all handled by the types of people who couldn't even program Hunt the Wumpus in BASIC.

Programmers of the world UNITE and seize the IDEs of production!

Well said!!!

[imrae]

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...

[Markus Krause]

'"Any and all prior VST 2 and/or VST 3 Plug-In SDK Agreements between Steinberg and the Licensee shall be automatically terminated by signing this Agreement."

That Steinberg made an additional clause in new contracts is really sneaky. Thanks for pointing this out! I will not sign any new contracts from Steinberg.

I agree with the above suggestions. To be safe we devs just need to write our own 'VST 2.4 compatible' SDK and release it as open source. Steinberg can't prevent us from doing this.

The VST3 SDK is a complete mess. I have worked with for one year and it is horrible and has no proper Midi support. It is bloated, over-engineered, complicated, full of bugs, with a bad documentation and doesn't even compile properly on many machines. It was the most frustrating experience in 25 years of software-development

[discoDSP]

To be safe we devs just need to write our own 'VST 2.4 compatible' SDK and release it as open source. Steinberg can't prevent us from doing this.

Best idea on this thread yet.

Not even a big project like JUCE can solve some serious VST3 issues.

[melomood]

'"Any and all prior VST 2 and/or VST 3 Plug-In SDK Agreements between Steinberg and the Licensee shall be automatically terminated by signing this Agreement."

That Steinberg made an additional clause in new contracts is really sneaky. Thanks for pointing this out! I will not sign any new contracts from Steinberg.

I agree with the above suggestions. To be safe we devs just need to write our own 'VST 2.4 compatible' SDK and release it as open source. Steinberg can't prevent us from doing this.

The VST3 SDK is a complete mess. I have worked with for one year and it is horrible and has no proper Midi support. It is bloated, over-engineered, complicated, full of bugs, with a bad documentation and doesn't even compile properly on many machines. It was the most frustrating experience in 25 years of software-development

This is what I'm ending up with sooner than later?? Gee. Can't wait

[lkjb]

I agree with the above suggestions. To be safe we devs just need to write our own 'VST 2.4 compatible' SDK and release it as open source. Steinberg can't prevent us from doing this.

I think I've read this thought (clean room design) a few times here but the main problem is that nobody seems to dare actually doing it. This would most certainly be highly appreciated by lots of developers but than again big companies (Cockos etc.) probably don't care enough and small developers won't risk a law suit.

Another grey area is juce_VSTInterface.h (in modules/juce_audio_processors/format_types) which was part of JUCE up until tag 5.3.2. The enums are all named differently but it shouldn't be too much work to compare them with later versions of JUCE that use the actual VST2 enum names.
The interface has been written by the JUCE team so if one has a JUCE license using it shouldn't be in violation of anything from Steinberg. Once again the question remains who'd dare risking a law suit over this which I see as the main issue here. Talk is cheap.

[Kott]

There was a stories when Steinberg pushed the copyright notices to authors of VST2 re-implementations: http://linux-audio.4202.n7.nabble.com/G ... 06190.html

anyway it's hard to kill the freedom, you can find vestige.h in many opensource projects, and there is another attempt: https://git.iem.at/zmoelnig/FST or

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

[Kott]

I agree with the above suggestions. To be safe we devs just need to write our own 'VST 2.4 compatible' SDK and release it as open source. Steinberg can't prevent us from doing this.

I think I've read this thought (clean room design) a few times here but the main problem is that nobody seems to dare actually doing it. This would most certainly be highly appreciated by lots of developers but than again big companies (Cockos etc.) probably don't care enough and small developers won't risk a law suit.

Another grey area is juce_VSTInterface.h (in modules/juce_audio_processors/format_types) which was part of JUCE up until tag 5.3.2. The enums are all named differently but it shouldn't be too much work to compare them with later versions of JUCE that use the actual VST2 enum names.
The interface has been written by the JUCE team so if one has a JUCE license using it shouldn't be in violation of anything from Steinberg. Once again the question remains who'd dare risking a law suit over this which I see as the main issue here. Talk is cheap.

As I wrote Cockos Reaper has support for free LV2 format.
Accordin JUCE's VST implementation, there is a fork of JUCE with updated VST headers from 5.3.2 https://github.com/DISTRHO/juce/