Lmms: VST3 Support

[T0NIT0RMX]

Hello,
I'm re-opening issue #2352
It was from 2015, it was a copy-paste, and today, in 2018, the context is different.

Context :
On the 1st Oct 2018, Steinberg stopped suporting VST2.
What does that means ? (The way I understand it, based on this topic)

• For devs who have a license : they can freely release new VST2 plugins.
• For devs who don't have a license, unfortunately, they are not allowed to distribute VST2 in any ways, and they CAN'T ask for a license.

Since may, I'm working on a big project, a free EDM synthesizer, using Cabbage framework..
Unfortunately I can't release it as a VST2, because I'm too late in the game...

The only way I will be able to distribute it is by the form of a VST3, which support GPL3 licensing.

Request

• Implementation of VT3 support for LMMS

I think it would be a really good improvement for LMMS, and I'd be pleased if my plugin could be compatible with the DAW I use.

Unfortunately, my knowledge to add this support is I think, too limited to lead the project, but I would be pleased to help & learn, so if you guys have knowldge about it, feel free to share it here so I can learn how it works in the same time (I know some devs have solid knowledge on this field, and would be interested to implement VST3 support for LMMS)

Thanks in advance,

[T0NIT0RMX]

@jasp00 @DomClark @PhysSong Could you guys help here ?
Thanks in adance

[jasp00]

For devs who don't have a license, unfortunately, they are not allowed to distribute VST2 in any ways

You can always use aeffectx.h from LMMS. There is no reason to ever drop VST2 support.

I do not think VST3 support is unwelcome. It should be optional because LMMS is GPL-2+. I believe this feature could be in 1.3.0, since you are volunteering.

Speaking for myself, 1.2.0 is the priority, so I will probably not help yet.

[T0NIT0RMX]

You can always use aeffectx.h from LMMS, they are not allowed to distribute VST2 in any ways

I don't talk about droping VST2 support in LMMS, but in Cabbage, the VST2 support will be dropped, and I don't know if it's really possible for Cabbage to use Vestige, because it relies on JUCE, so it would need a kind of wrapper to work with Vestige, if I understand well.
Also, at the moment I don't really understand why using this aeffectx.h header would allow me to release VST2 plugins, Steinberg seems very clear about that so..

I would love a support of VST3 yeah, and @DomClark told me that he worked on a VST3 host, so I guess he could be able to implement that support (of course after lmms 1.2)

I'm volunteering, I don't have much knowledge in the LMMS project, but I'm here to learn.

[jpcima]

@T0NIT0RMX
I implemented VeSTige support in JUCE for my own needs, and I submitted an answer at a Debian bug of the same topic. It's not yet answered but you may find this of interest.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913915

[T0NIT0RMX]

@jpcima
Sorry for the delay, i missed the notification mail..
so I read the mail on your link and this seems like a great solution !
I wonder something tho : do you think I could get Cabbage to work if I put your modified JUCE and then compile ? Do you used the same methods (sorry maybe it's not the right word here, I'm still learning) as in the original JUCE Version ?

[jpcima]

@T0NIT0RMX
A simple way may be to follow identical steps as the Debian maintainer did to upgrade Juce without breaking the packages.
The former GPL'd VST code from 5.3.2 can be backported in the recent releases, and the debian sources provide the way to patch it.

Inside the debian source archive, you will be able to locate needed files.

• the patch debian/patches/debian_vst.patch which reverts to GPL-style 5.3.2 VST
• VST interface 5.3.2 ./debian/extra/juce_audio_processors/format_types/juce_VSTInterface.h

[T0NIT0RMX]

@jpcima
Thanks for the explanation.
Let's suppose I do this, will the resulting JUCE be free to all Steinberg code ?

At first sight, it seems like I'm just downgrading JUCE, but it would still contain some proprietary code, is this true ?

This is a real problem for me, I'm trying to find a way to build a vst from Cabbage using no proprietary vst code (so using vestige seems the way to go)

[jpcima]

Let's suppose I do this, will the resulting JUCE be free to all Steinberg code ?

It will be Steinberg-free. If the solution was fine enough for Debian, I expect it's probably good for free software use.

The former Juce version contained its own substitute of VST2 SDK, somehat similar to vestige, lincensed under GPL3 as you can observe by a look at the source file.
https://github.com/WeAreROLI/JUCE/blob/5.3.2/modules/juce_audio_processors/format_types/juce_VSTInterface.h

You can look at juce forums for information, the VST2 issue has been discussed at great length.

[T0NIT0RMX]

Alright ! I get it !
But what about _your_ JUCE fork with vestige ? I mean, okay going back to an old version of JUCE may solve the problem, but wouldn't it be better if I use you vestige JUCE in Cabbage ?

Sorry for all the questions, im still learning things about all of this and now I have to figure out a solution to release my vst legally for free, if applying the patch you mentioned earlier can help I'll go with it ! I may still have some other questions during the process

I just need to make sure their version was legally reverse engineered

[jpcima]

The use of vestige remains probably the option of least legal uncertainty.
I am just a developer not lawyer, and don't have the clear answer, and probably no one else has.

What is known: (1) vestige has remained unattacked after years of use, including after the increased hostility of Steinberg towards legacy VST (2) Juce VSTInterface backporting was taken as official method for Juce 5.4.1 in Debian Sid.

Just know that vestige comes with a few elements of lost functionality in comparison to Juce or SDK. (as listed on Debian thread)

I just need to make sure their version was legally reverse engineered

Despite that it's marked as GPL, Juce VSTinterface most likely was not. As I recall, it was agreed for distribution in that way by an agreement of the two companies.

[T0NIT0RMX]

Thanks, I documented on the topic from JUCE forum
And now, since October 2018, it seems like the old implementation of vst used in previous versions of JUCE is now forbidden (but again it's a hard to understand topic)

So that seems to remove using JUCE old implementation fromy list of options.

So I will use your JUCE fork, or maybe I can use Cabbage's JUCE and then apply some of your commits to it to make it work with vestige ?

What commits are actually responsible of that change ?
(Btw, just saw some of your comment on a tuxfalily forum, seems you are french too, so if I can contact you by email and write in french it would be easier I think)

[jpcima]

if I can contact you by email and write in french it would be easier I think

I'm reachable on linuxmao IRC and I watch a number of forums there, and the mail address is on the website on my profile page. It's better to continue the discussion somewhere else, given it's somewhat deviated of the original VST3 topic.

[Spekular]

Closing and consolidating into #5433

[DomClark]

VST3 is VST in name only - as far as the code goes, it's as different to VST2 as something like LV2 or LADSPA is. I don't think it's meaningful to consolidate it with other VST issues unless the intention is to create a generic "external plugins" meta-issue.

[Spekular]

I've hidden off-topic comments and removed the preview of Tone-Z to keep this issue more focused. As pointed out in #5746, it strayed from the topic quite a bit for a while.

[LoveBodhi]

VST2 SDK is non-free (no longer licensed by Steinberg!) and this doesn't support VST3 (Stardream Error Code G1811)......