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

DSP, Plug-in and Host development discussion.
User avatar
KVRAF
2678 posts since 15 Oct, 2017 from U.S.

Post Sat Apr 17, 2021 8:29 am

nah That couldn't be the only reason

KVRAF
4366 posts since 22 Nov, 2012

Post Sat Apr 17, 2021 9:01 am

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.

User avatar
KVRAF
3919 posts since 6 Nov, 2009

Post Sat Apr 17, 2021 11:58 am

Dasheesh wrote:
Sat Apr 17, 2021 9:01 am
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.

User avatar
KVRian
783 posts since 25 Sep, 2014 from Specific Northwest

Post Sat Apr 17, 2021 1:15 pm

arkmabat wrote:
Sat Apr 17, 2021 11:58 am
Dasheesh wrote:
Sat Apr 17, 2021 9:01 am
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?!?

User avatar
KVRAF
3925 posts since 8 Mar, 2004 from Berlin, Germany

Post Sat Apr 17, 2021 1:42 pm

syntonica wrote:
Sat Apr 17, 2021 1:15 pm
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 :shrug:
Last edited by Music Engineer on Sat Apr 17, 2021 11:12 pm, edited 6 times in total.

User avatar
KVRian
783 posts since 25 Sep, 2014 from Specific Northwest

Post Sat Apr 17, 2021 3:00 pm

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! :lol:

KVRAF
4370 posts since 21 Sep, 2005

Post Sat Apr 17, 2021 3:18 pm


KVRAF
2404 posts since 17 Sep, 2016

Post Sat Apr 17, 2021 3:31 pm

syntonica wrote:
Sat Apr 17, 2021 3:00 pm
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! :lol:
Well said!!! :clap:
Windows10; plugins from AAS, Ableton, AIR, Ample, Arturia, Cakewalk, Cherry, DiscoDSP, Fathom, IKM, Initial, iZotope, KV331, NI, PluginGuru, PreSonus, Surge, TAL, Tone2, Toontrack, Tracktion, u-he, UJAM, UVI, Vital, Waves, XLN ...

KVRAF
1621 posts since 2 Jul, 2010

Post Sat Apr 17, 2021 11:57 pm

syntonica wrote:
Sat Apr 17, 2021 3:00 pm

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

User avatar
KVRian
922 posts since 2 Jul, 2018

Post Sun Apr 18, 2021 12:06 am

'"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 :pray:
Last edited by Markus Krause on Sun Apr 18, 2021 12:28 am, edited 2 times in total.
Tone2 Audiosoftware https://www.tone2.com

User avatar
KVRAF
5202 posts since 18 Jul, 2002

Post Sun Apr 18, 2021 12:25 am

Markus Krause wrote:
Sun Apr 18, 2021 12:06 am
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.
Synthesizers • Bliss sampler • Effects • Soundware
https://www.discodsp.com/

User avatar
KVRAF
2678 posts since 15 Oct, 2017 from U.S.

Post Sun Apr 18, 2021 1:56 am

Markus Krause wrote:
Sun Apr 18, 2021 12:06 am
'"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 :pray:
This is what I'm ending up with sooner than later?? Gee. Can't wait

KVRist
184 posts since 13 Oct, 2012

Post Sun Apr 18, 2021 2:36 am

Markus Krause wrote:
Sun Apr 18, 2021 12:06 am
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.

KVRist
414 posts since 12 Mar, 2013 from Russia, Vladivostok

Post Sun Apr 18, 2021 2:44 am

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.

KVRist
414 posts since 12 Mar, 2013 from Russia, Vladivostok

Post Sun Apr 18, 2021 2:47 am

lkjb wrote:
Sun Apr 18, 2021 2:36 am
Markus Krause wrote:
Sun Apr 18, 2021 12:06 am
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/

Return to “DSP and Plug-in Development”