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

[OBSOLETE160530]

[DELETED]

[rafa1981]

One question, is LV2 imposing a build system (waf/meson) to the plugin writer (as JUCE does with CMake and the projucer) or is it just for building some LV2 related binaries (e.g. to do stuff with Turtle files)?

[mr.ardour]

In order to gain momentum we need to see some braindead simple tutorials for people that have never and will never see Linux, don't want to have to learn waf or any other new thing, no matter how awesome it is...just brain dead simple..even better if in conjunction with free tools like Visual Studio Code, Xcode, etc.

People who actually use those tools would need to do this. LV2 is build-system agnostic. The details of "how to build my plugin as an LV2" depend vastly, overwhelmingly more on your plugin than they do on LV2. This is even more true if you were to hand-create the metadata rather than automate that as part of the build system. At that point, LV2 for the plugin is just a header file (surprise, just like VST2

but having to dig into a whole bunch of build technologies and making sure you have all the right libraries installed, [ ... ] somewhere half way between linux-land gotta install a buzzillion libraries ....

Once again, there are NO libraries associated with LV2 for plugin authors.

[*]Roll out an SDK kit that will make it brain dead simple easy for any host to include LV2 hosting support. Make it a one day or less job and I think some hosts would consider it.

The idea that you can trivially add a new plugin API to an existing DAW (not necessary a simple plugin host, but a full DAW) is almost certainly misleading. Even if all the pieces map fairly easily to existing stuff (e.g. the existing VST2 support), I don't think you're going to get such as task finished in "one day or less". Maybe two

As usual, handling the GUI is the tricky part. Not only is there more variation at this level between existing plugin implementations, but integration into the host's own GUI code is much more likely to run into issues. This is actually even worse on Linux, where there' s no usable lowest-level common denominator across GUI toolkits, and developers have often imagined they could just use Qt or GTK without understanding how unsuitable these are.

[syntonica]

1. convince the JUCE team to include it as a plugin target, and if possible as an LV2 host also. There are a lot of JUCE plugins that could ported almost instantly that way. I know there is a JUCE fork already, but it needs to become something in the mainline up to date version of JUCE...and they would probably have "LV2 now included" pasted all over their marketing, which would also help.

https://github.com/juce-framework/JUCE/issues/123

It's unlikely JUCE will add LV2 support officially...

That discussion is now a couple of years old. With the current VST 2/3 developments, it may be time to raise the issue again.

(Side note: I'm not interested in using JUCE, but I am interested in toppling the current plugin format stranglehold...)

[Dewdman42]

Thanks for that link. Well the last comment from Julian was 2 years ago...and he seemed to focus more on the linux open source aspect then to the simple question of addressing LV2 plugin targets... At that time I do not think he was even considering the Steinberg VST fiasco issue on Mac and Windows...which he should. I know they are not exactly Steinberg fans either.

I think its still worth nudging them continuously...but it also sounds like if we want to get anywhere with creating momentum it probably won't come from them, at least people have perceived them that way. Lately Julian seems more interested in SOUL. I've been asking for certain features needed in JUCE since years ago...without any response, so in a certain way JUCE development has basically stopped, they are just barely maintaining it now it seems.

it might be worth dragging iPlug into this too. (or trying at least).

[FigBug]

Lately Julian seems more interested in SOUL. I've been asking for certain features needed in JUCE since years ago...without any response, so in a certain way JUCE development has basically stopped, they are just barely maintaining it now it seems.

If you're not aware, JUCE has been sold. Julian is not employed by the new owner and longer involved.

That said the JUCE team is hiring, they just released accessibility support. So some things are happening, but without any sort of roadmap, it's hard to know where it's going.

[EvilDragon]

Don't think Jules is with JUCE anymore after the iLok buyout. He's now focused on SOUL.

Now iPlug might be a good thing to check out if Oli would be interested.

[x42]

One question, is LV2 imposing a build system (waf/meson) to the plugin writer (as JUCE does with CMake and the projucer) or is it just for building some LV2 related binaries (e.g. to do stuff with Turtle files)?

No build system imposed. You can use whatever works for you.
It's really just C/C++ with a couple of header files for the plugin (personally I prefer plain Makefiles to build plugins YMMV). You could even copy those header files into your project.

The meta-data .ttl can be hand-written text-files or generated (replace from some template).

I expect someone with XCode or MSVC experience can create a re-usable plugin-template project in under 30mins, perhaps even in under 10.

[syntonica]

Don't think Jules is with JUCE anymore after the iLok buyout. He's now focused on SOUL.

Now iPlug might be a good thing to check out if Oli would be interested.

Poor Oli!

"We know you were out of the room, but we all voted and you're now adding LV2 support to iPlug2!"

I'm sure there's somebody who's interested enough to add it, however. Just a matter of finding them.

[Super Piano Hater 64]

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.

Does this still apply to people whose VST2 licenses were canceled/replaced by a VST3 license (before Steinberg changed its mind about that)?

[S0lo]

For those that use JUCE, if you are anything like me and are fed up with it, consider https://github.com/DISTRHO/DPF
It is a super minimalistic toolkit/framework I did after many issues with JUCE under Linux, and yes their lack of interest for LV2.
Some initial documentation is at https://distrho.github.io/DPF/
Still a work-in-progress, but can already generate LV2 and VST2 plugins, among other things.
I am currently overhauling the graphics backend to be more robust. It will be able to use vstgui4 as-is for the UI in the future too.
VST3 support is in the plans, with a fair bit of work already done.

[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.

Does this still apply to people whose VST2 licenses were canceled/replaced by a VST3 license (before Steinberg changed its mind about that)?

VST3 license under 2.3 has a similar clause, but it is tricky. In the EU reverse engineering an APIs is legal, so the clause may be void.
Then again large parts of the VST SDK is implementation, that may or may not fall under "interface".

[milkmiruku]

Aside from https://github.com/DISTRHO/JUCE there is also https://github.com/lv2-porting-project/JUCE by KottV.

Rough edges are getting fixed https://github.com/surge-synthesizer/surge/issues/4030 and CMake integration is a WIP https://github.com/DISTRHO/JUCE/pull/13 https://github.com/benthevining/imogen/issues/8

Aside; https://github.com/iPlug2/iPlug2/issues/105 is an interesting and amusing thread.

[milkmiruku]

And, for a fifth post to disable that auto-admin link protection thing, a note that LV2 also does "CV"; https://linuxmusicians.com/viewtopic.php?t=20701

[Kott]

Aside from https://github.com/DISTRHO/JUCE there is also https://github.com/lv2-porting-project/JUCE by KottV.

Rough edges are getting fixed https://github.com/surge-synthesizer/surge/issues/4030 and CMake integration is a WIP https://github.com/DISTRHO/JUCE/pull/13 https://github.com/benthevining/imogen/issues/8

To clarify. My fork is the copy of falkTX wrappers, I've made additions to CMake for LV2 support. PR with CMake support to main DISTRHO repo is pending.