Hosting VST2 plugins under VST3 SDK/License

I started developing plugins in early 2019 and therefore missed the deadline to sign the VST2 SDK license agreement. I know Steinberg’s decision to stop giving out VST2 licenses has been discussed to death, but I’m still in need of a solution for a plugin I’m currently developing.

The plugin I’m building has the ability to host other plugins (sort of an effects rack). While I’m fine with not being able to release my own plugin as VST2, I absolutely do need to be able to host other VST2 plugins. There are just so many plugins out there that have not been ported to VST3, and many of them never will be.

As I understand it, the VST3 SDK provides a wrapper that allows VST2 only hosts to host VST3 plugins, but not the other way around. I know there are plugins out there that will wrap pretty much any format known to man, but these are not the kind of plugins your average user tends to own and/or use.

I can think of 2 possible solutions:

  1. The legal solution: Aquire a company that (in the capacity of a legal person) has licensed the the VST2 SDK from Steinberg.

  2. The technical solution: License a wrapper (in binary form) from someone who has licensed the VST2 SDK from Steinberg. Essentially, this would be the VST2 wrapper that is missing from the current SDK, and would allow me to wrap VST2 plugins and treat them as VST3 in a way that is transparent to the user.

Now, being a technical person I lean heavily towards solution 2 and I wonder if anyone has experience with this kind of thing?

Also, please do let me know if I’m missing something…

I did not know that you cannot host VST2 plugins without a license from Steinberg. I thought it was only if you intended to release VST2 plugins. (I am also working on a sort of pluginhost that would need to host VST2 plugins.) Do you have a link or documentation to that effect? Can anyone else confirm?

The license is for plugins and/or hosts.

2 Likes

Interesting. What does the VST2 license say about developing products for others? The VST3 license has provisions for this.

At any rate, I see nothing (so far) that would prevent a person or company with the appropriate licenses to “publish” a binary wrapper and someone else to use it. It would essentially be a very simple VST3 plugin that can host a VST2 plugin transparently.

Wow, that sucks. Can VST2 licenses be transferred (i.e. can someone who is no longer using one sell it to some other developer?)

No, transfers are not allowed. I believe the only way you could get your hands on a VST2 SDK license today would be to buy a company that already has one.

But… I don’t really want to develop VST2 plugins, I just want a wrapper so I can host them.

It may not matter in your case, since you sound like you may be working with audio plugins only, but AFAIK VST3 format severely compromises the ability to send and respond to MIDI events like controllers, pitch bend, aftertouch, etc. Since I’m working with MIDI and audio, a VST3 wrapper probably wouldn’t work in my case.

1 Like

It’s a HUGE problem for me, but I’m more interested in finding solutions than whining about it.

I believe there are workarounds for your problem, try to search the forum.

Please do not hijack this thread.

Respectfully, I’m not whining, and I’m not hijacking the thread, I’m heavily interested in a solution as well. There are not good workarounds for transmitting MIDI, I’ve authored several threads on this here already.

Secondly, with regards to your suggested solution, maybe I’m missing your logic, but how does having a VST3 wrapper solve the problem?

You have a Plugin Host, with a licensed VST3 wrapper that wraps VST2 plugins. So in order to run a VST2 plugin, you have to load it into your VST3 wrapper, at which point, you are still “hosting” a VST2 plugin, inside your product, it seems. It’s just a layer of redirection.

The license concerns the SDK (which contains the header files needed to compile VST2 plugins/hosts), not the binaries you use the SDK to produce.

As long as you have a VST2 SDK licence you are allowed to publish VST2 plugins/hosts, and others are allowed to use them (in binary form) without a license from Steinberg.

I posted a link about MIDI support in VST 3 on one of your other threads that might be of interest to you.

I would appreciate if we keep posts on this thread on the topic of hosting VST2 plugins without a VST2 SDK license.

Thinking theoretically, would this path be legally valid?

Company A has acquired in the past the VST2 SDK license
Company B is interested in acquiring it now

Company B purchases/merges with Company A and thus acquires the rights for the VST2 SDK license.

Now, what happens if Company B splits in two companies, say C and D?
Are them both legally allowed to use the VST2 SDK license?

If so, a John Doe owning a VST2 SDK license, could set up a company that gets purchased by and then split out of bigger companies to propagate to them the right to use the license (possibly at the price of renaming the resulting company every time)

@yfede: Maybe… but probably too complicated to be a real option :slight_smile:

But what if a company that has both a VST2 and VST3 license were to put out a (binary) wrapper that would allow someone like me to load wrapped VST2 plugins as VST3 plugins?

I noticed that the KnownPluginList class in Juce will happily scan for VST2 plugins even if the VST2 header files are not present - it just won’t instantiate them. But what if I could just pass the VST2 plugin filename to a wrapper plugin that loads it and presents it as an AudioProcessor instance to the host? This could be completely transparent to the user.

A developer that has signed both the VST2 and VST3 agreements would obviously be able to release such a wrapper plugin in binary form. And a developer with a VST3 license should be able to link to this wrapper (at compile time or run time), since it would only require the VST3 SDK… it would just be a VST3 plugin after all.

Unfortunately, I don’t have a copy of the VST2 SDK license agreement, so I’m not sure if there are any restrictions that would need to be considered.

Beware of the temptation to pass around C++ objects across different binaries! There are a handful of topics here on the forum explaining why that’s a very hard thing to do.

Well… what I’m talking about here would essentialy by a VST3 plugin that is also a VST2 host, which is definitely feasible.

Actually, I already have a VST3 plugin that will host other VST3 plugins and I’m pretty sure it will host VST2 plugins too. All that would be needed is a way to tell the wrapper which VST2 to load (if this is to happen without the users involvement) but that could probably be solved somehow.

Interesting, whether this would violate the VST2 agreement or not. I imagine it might, since the company releasing the product still has not signed the agreement… I’d be interested in a confirmation too!

I just got hold of the VST2 SDK license agreement. It states that the licenscee is allowed to “publish products under his own name”, and that a 3rd party that wants to “publish” this product under his name instead must also obtain a license to the VST2 SDK.

So (in my understanding), Developer A can to “publish” a wrapper “under his own name”, and this wrapper can be used by Developer B and/or any end user. However, Developer B cannot take the wrapper (in binary or source code form) and rebrand it as his own.

The language in the agreement is not very clear (obviously written by a German) and I’m not sure whether Developer B can distribute Developer A’s wrapper with his product or not. But then again… these days distribution equals download, and I guess Developer B’s installer could just prompt the user to download the wrapper from Developer A’s website if they want VST2 support. If it’s even an issue at all, that is.

I think this model might be feasible but it would probably be a good idea to run it by a lawyer who actually knows what he’s talking about :slight_smile:

1 Like

Yes, I guess more likely to abide by the agreement if the wrapper is a DLL. Which (from previous experience) may be a pain to use in a plugin…

I think the wrapper would definitely need to be in separate binary. But that binary would just be another VST3 plugin, i.e. “vst2wrapper.vst3”… :slight_smile:

The VST3 plugin I’m developing already has the ability to wrap other VST3 plugins (Juce has everything you need to do this), and therefore it would be able to load the wrapper too.

The wrapper would essentially do the same thing, although it would wrap VST2 plugins rather than VST3.

In the end, my solution would involve “double wrapping” the VST2 plugin but I don’t think that would be a problem.

Ah OK I think in that case you or onto something :wink:

1 Like