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

[imrae]

https://forums.steinberg.net/t/vst-3-sd ... /201638/18

Thanks for the link. I'm almost surprised that Steinberg might actually have listened to concerns from developers.

I guess they did not want an all-out war with the VST developers.

The post says it will be back in the next version and makes no apology or justification. Is there another post somewhere else that acknowledges the problems this will cause?

[OBSOLETE160530]

[DELETED]

[mystran]

You do not need a VST2 license, since it does not use the official SDK but the free/GPL vestige header file.

GPL has nothing to do with free (as in speech). GPL is poison. Even if I want to write free (as in speech), open source code, I cannot touch anything having to do with GPL, because that would then place unreasonable restrictions on how I can allow other people to use my code.

[OBSOLETE160530]

[DELETED]

[EvilDragon]

There's plenty of MIT licensed stuff too, if GPL doesn't float your boat...

GPL is quite contagious/acts like "poison", but it's not poisonous in its intent. IMO.

[x42]

I cannot touch anything having to do with GPL, because that would then place unreasonable restrictions on how I can allow other people to use my code.

For the case at hand (lv2vst), the license applies to the bridge, not the plugin that is being bridged. That is dynamically loaded at runtime.

You can load a closed source plugin just fine in an open source host or vice versa.

[counterparty]

Honestly, as a dev, a standard for which any given implementation could be entirely incompatible with other implementations gives me bad vibes.

I can imagine those support emails asking why your LV2 plugin didn’t work with their LV2 host.. ‘sorry, it has to be a special kind of LV2 host that supports RandomExtensionA 1.2, RandomExtensionB 1.34 or above, and RandomExtensionC 0.9 or below’.

Or maybe why your host doesn’t support the plugin they just bought.. are you going to keep a list of every compatible plugin?

I think this kind of thing works ok in open source where people are paying with their time to get things working but good luck when money is involved.

[OBSOLETE160530]

[DELETED]

[x42]

Honestly, as a dev, a standard for which any given implementation could be entirely incompatible with other implementations gives me bad vibes.

Just be clear, LV2 is not such a standard. Extensions are always optional never required for core functionality.

It's really like with PreSonus Extensions: e.g. Q: "Why do I not see the track name and host's fader-gain in the plugin's UI?" A: "Because your DAW does not support VST3 IContextInfoProvider2".

or perhaps stating that your plugin only works in a host that supports ARA.

[mystran]

There is not really an issue that happens at all right now.
The main extensions are supported by all hosts, the more esoteric ones are all optional.
The essential stuff (dealing with MIDI, files, state, time and UI) are pretty much in all hosts by this point.

Need at least http://lv2plug.in/ns/ext/instance-access as well to get stuff done.

[S0lo]

You can load a closed source plugin just fine in an open source host or vice versa.

"or vice versa"

Does that mean I can dynamic link an open source binary (say DLL) and use it in a closed source project? I was under the impression that this was a grey area, unless an explicit exception was made (or use the LGPL instead of GPL)

https://en.wikipedia.org/wiki/GPL_linking_exception
https://stackoverflow.com/questions/171 ... pplication

[syntonica]

If you really want a wrapper, let me give you a few extra links as references.
https://github.com/x42/lv2vst
https://gitlab.com/drobilla/mda-lv2/-/tree/master/lvz
https://github.com/DISTRHO/juce/blob/ma ... rapper.cpp

(EDIT: The JUCE LV2 wrapper has a bunch of legacy code that nowadays we have utility functions, plus all the checks around time types are unnecessary. This is 8 years old code that I barely update, just enough to keep things working.)

Wow! Thanks for these. Glancing over them, they tell me more about LV2 in a couple of simple examples than me trying to read the docs ever would

[FigBug]

You can load a closed source plugin just fine in an open source host or vice versa.

"or vice versa"

Does that mean I can dynamic link an open source binary (say DLL) and use it in a closed source project? I was under the impression that this was a grey area, unless an explicit exception was made (or use the LGPL instead of GPL)

https://en.wikipedia.org/wiki/GPL_linking_exception
https://stackoverflow.com/questions/171 ... pplication

Probably not. Depends if the application and the DLL are considered a 'single combined program' or not. If your application depends on the DLL to function, it's pretty hard to argue that they are not a single combined program.

However with a DAW and a plugin, it's pretty easy to argue they are not a single combined program. The DAW works fine without the plugin, the plugin works fine in multiple hosts. They are in no way connected.

[bero]

I actually almost never write here and am more of a silent reader and otherwise a coding-wise silent just-doer, but on this topic I have to write something here again too.

For my BR404, BR808 and Sobanth VSTi plugins I didn't use the original VST2-SDK, but made my own VST2-compatible Object-Pascal-based mini-SDK purely based from public informations, which worked quite well. Some people ported this from Object-Pascal from the BR808 GitHub repo to C++ (e.g. the OpenMPT guys) for to be no longer exposed to the arbitrariness of Steinberg.

And as part of the development of my (unreleased) own Indie-DAW, I did basically also the same for VST3, but here primary for the plugin host features, so I also now have my own VST3-compatible Object-Pascal-based mini-SDK. Even though it was a bit more Low-Level-ABI-workaround-hacking-work due to certain "It is not quite COM"-ABI issues at the VST3 specification, but I've sorted them mostly out, so almost all VST3 are working in my Indie-DAW now, except that the most of the iZotope VST3 plugins makes still problems in my Indie-DAWs. Consequently, I am also here independent of the Steinberg arbitrariness, at least here with the legality within the EU. But the U.S. can be a different topic regarding this problematic.

And slowly I'm thinking if my Indie-DAW should support LV2 as well in addition to VST2 and VST3. Right now it already runs on Windows and macOS. Linux support would be a matter of only a few days here. And I believe I'll also add LV2-Support after I've been read this thread now. But not immediately, but I have now planned for that.

[x42]

I didn't use the original VST2-SDK, but made my own VST2-compatible Object-Pascal-based mini-SDK purely based from public informations, which worked quite well.

Keep in mind that you are only allowed to do that if you have not signed the official VST2 SDK license in the past. By accepting that license you agreed not to re-work or reverse engineer it.