vst3_pluginterfaces

This is great news! At the same time it's too little too late. I still won't forget how they killed the VST2 SDK and came after people who hosted copies. This was terrible for people who tried to build existing open source VST2 plugins. It was even worse for people who wanted to write a VST2 host, but couldn't get a license anymore. This was at a time when VST3 support was far from universal and many plugins didn't ship VST3 versions. (Not to mention all the existing plugins that never will.) I mean, these "SDKs" are just goddamn header files! *) They shouldn't have been proprietory in the first place. Now, if they also re-release the VST2 SDK under the MIT license and apologize for their crass behavior, then I will actually give them credit. /rant off *) Yes, the VST3 SDK is huge, but the only things you really need are the headers in ht

Clap doesn't allow describing plugin in a manifest (like VST3 and LV2 do). This allows to scan for plugins faster. Also, CLAP uses 3 or 4 methods to represent MIDI data (MIDI1, MIDI1 + MPE, MIDI2, CLAP events). This requires to write several converters when implementing a host. But, CLAP is much simpler and doesn't use COM-like system (VST3 resembles a Windows COM library with endless interfaces and GUIDs). Also, VST3 interfaces in SDK are described as C++ classes with virtual functions (example: [1]), and I wonder how do they achieve portability, if the layout for such classes (vtables) is not standardized and may differ across compilers. [1] https://github.com/steinbergmedia/vst3_pluginterfaces/blob/3...

This is the absolute worst part of VST3. These 2 soul-crushing lines in the build file: https://github.com/steinbergmedia/vst3_pluginterfaces/blob/m... # pluginterfaces should actually be a header-only library, # but it has some sources as well which need compilation. Should theoretically be fixable right, so that it's purely the interfaces and doesn't need compilation? Why on earth did they do it like this?...

> What Cockos did with Reaper and their VST "extensions" is absolutely not part of Steinberg's conception of VST. I tend to disagree. What else is the purpose of the effVendorSpecific/effCanDo and audioMasterVendorSpecific/audioMasterCanDo opcodes? > two organizations could "define" an extension that uses the same integer value for the audiomaster callback Yes, this is indeed a problem. > LV2 uses URI's to identify extensions And VST3 uses COM like interfaces with GUIDs. I think it's just two different ways to achieve the same thing. > Do you know that the SDK Steinberg distributes for VST3 is larger than the entire Ardour codebase? :-) 99% of the VST3 "SDK" is just unnecessary cruft, the actual plugin interface is pretty small (although not as small as VST2). I've written a cross-platform VST3 host, and "pluginterfaces" is really all you