LinuxMusicians

Because of the latest Steinberg news about deprecating the VST 2 SDK, and their plans to make it unavailable, I wanted to see if I could make my plugin framework more "future proof", and compile the plugins using the vestige aeffectx.h header instead of the official SDK.. I'm only using the lowest level header files (not the classes they built on top of that), but it failed miserably - too many undefined constants, types and structures.

And that got me thinking - how much effort would it take to "fix" the vestige header so that it could become a drop-in replacement for the Steinberg SDK?

I could do most of this myself, but as far as I understand things, I might be considered "tainted", since I have used the Steinberg SDK for years and years, and published several plugins using it..

But maybe I could try to write some text or specification, and then some others could actually 'punch it in'?

https://en.wikipedia.org/wiki/Clean_room_design

"Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification.. The specification is then implemented by a team with no connection to the original examiners."

Any thoughts?

thanks..
but, argh.. licensing is a mess..
i think i will keep the source code private for the time being, and only publish binary files..

ehh, ok..
thanks for pointing it out.
i am (or was) thinking about releasing the library/framework code as opensource, and was mainly wondering about my options..
didn't look too deeply into licensing and stuff yet..

The VST SDK (< 3.0) is not GPL, so what is your problem with licensing?

For your own code you can use any license you want provided you respect the licenses of any other foreign code you want to include.
Since you apparently wrote all code yourself, it comes down to respecting the VST license.

but, argh.. licensing is a mess..
i think i will keep the source code private for the time being, and only publish binary files...

You should be ok using the SDK to create binaries if you already have a copy of it - as far as I am aware the only issue is that you can't redistribute the SDK itself, therefore open source projects either had to rely on users being able to obtain the SDK from Steinberg, which it seems is now going to be more difficult, or, they could include something like vestige (but that might tie your project to the GPL which might not be the kind of license you require).

You might be able to release your code under whatever open source license you choose (or create) as long as you don't include / redistribute the vestige code - users could then obtain and include that if / when they build your plug-ins.

Of course it would be nice if Steinberg released the VST2 SDK under a completely free, non GPL, license if its now officially deprecated - but its possible to speculate they might instead prefer the opportunity to guide people towards VST3

(I'm not pro or anti GPL, and I understand the reasons for it, but my personal preference is that 'free' software be released under a 'do what you want, no obligation' license - after all, anything else has an inherent contradiction - freedom according to someone else's rules, which is just that, another set of rules)

hi again!
thanks for all replies and comments..

i'm sorry for not answering earlier, but i'm incredibly busy at the moment, with two of my bands/projects releasing albums at almost the same time, so i have my hands full with promotion and preparation stuff.. :-/

well, well..

i decided to postpone the licensing and opensourcing issues a little, and focus on adding a few more plugin formats to the library first.. especially lv2 and vst3.. i have to do quite a bit of 'massaging' to make it work with my current framework scheme, so we'll see how that goes..

- tor-helge

i have to do quite a bit of 'massaging' to make it work with my current framework scheme,..

If you're using X11 for your UIs then VST3 should be ok - you don't necessarily need to use cmake etc either, you can just compile the sdk/base library using whatever build system you want - and then compile and link your code / framework against it. If you are using your own UI framework then you don't need to include any of the VSTGUI code from the SDK either, which means you don't bring in any unnecessary GTK3 dependency, so it works out that you have minimal dependencies (which is always a good thing if you want binary compatibility across different distros / versions etc).

(You might need to pay attention to symbol exports on linux - I found that by default, ModuleEntry / ModuleExit weren't getting exported properly, which meant the host silently failed to call them. This could be important if you require the Init / Deinit functions to set anything up when the plugin .so is loaded / unloaded).

yeah, i'm using 'pure' x11 (or xcb, actually), optionally with cairo on top.. and no make files in sight here - i'm compiling from within codelite (my currently preferred ide), and/or using scripts.. i actually managed to compile/link the vst3 files, but i haven't tried to make an actually working plugin yet.. as usual, we'll see how things go..

thanks for the hint about symbol exports..