LinuxMusicians

Recently I've been around asking developers to move away from VST2, because it's proprietary, discontinued and redistributing its SDK gets projects DMCA'ed (rightly so, the problem was using proprietary code in the first place).

Initially I promoted VST3 because it's released under the GPLv3, however there is a lack of hosts on GNU/Linux and some experienced developers complained about its design and implementation. I myself got a segfault when I tried to run one of their demos, and their Github repository seems quite abandoned for something as important as it was supposed to be.

Since there is a bit of a plugin standard war right now (some DAWs have created their own formats, and I think I might have seen even a JavaScript-based format ), I think it's important that the GNU/Linux community sticks to one that works well and is managed independently: LV2.

But the initial barrier that many professional audio developers encounter is that right now they have experience with VST2 (or maybe AU) exclusively. So, to help them make the transition (and as a result, help us end users), it would be nice if a developer experienced with both VST2 and LV2 could write a guide to port VST2 plugins to LV2. Sadly, I have zero experience with VST and know a bit about LV2, so I'm just throwing the ball out there hoping someone will catch it

Understanding the concepts of LV2 and writing your first "Hello Sine" LV2 plugin isn't really that hard, and the official tutorial at lvplug.in does a good job of showing that. But I agree that a guide explaining how LV2 relates to other plugin formats from a technical standpoint and from a practical developer's standpoint would be good to have.

What I'm personally missing is a collection of short howtos, which show how to accomplish common but advanced tasks with LV2 and not only show the code to do it, but explain the concepts and coding techniques used.

For example:

* How to load files (waveforms, impulse responses, ...)
* How to let the user specify files to load
* How to display live frequency graphs, spectrograms or meters
* How and why to use the state extension
* How to handle MIDI input to control plugin state (and in which cases to leave this to the host!)
* How to handle MIDI input to control synth voices
* How to test and debug plugins and check conformance

Also, an overview of all the LV2 extensions and what they are good for would be nice. The reference documentation on the LV2 doesn't help in this regard at all.

Chris

What's your opinion about DPF, which allows a single project to be built as both LV2 and VST2? When I was getting ready to develop Dragonfly Reverb, I investigated Juce, DPF, and maybe some other frameworks that I've forgotten. I gave up on Juce when I was following the instructions and found that I needed to install some kind of custom IDE, the whole thing just seemed way more heavyweight than I wanted. With DPF it was really easy to just copy one of the example projects and start hacking. Admittedly, DPF has very simplistic GUI facilities, but in my minimalist opinion that was an advantage.

You probably mean the original poster, but I for one wholeheartedly recommend using DPF, if - for some reason - one isn't restricted to pure C. It spares the developer from having to mess around with .ttl file generation and you get LV2 and VST2 plugin format output for free.

When we did a small plugin development workshop at our local Open Source audio meetup, we also used DPF: https://github.com/osamc-lv2-workshop/lv2-workshop

I had very little experience with plugin development or even C++ before, but I was able to develop the example plugins and explain them to the other participants without too much sweat.

A good starting point may be adapting this very good guide on plugin development with WDL-OL to DPF:

http://www.martin-finke.de/blog/tags/ma ... ugins.html

I'd like to see JUCE have a LV2 export plugin.

This is very unlikely to happen in the "official" JUCE from ROLI. They have been asked to do that for a long time and never did anything about it. There's talk of bringing falkTX's JUCE fork, which already has LV2 support, up to date again. But that won't help with existing plugins, which use ROLI's JUCE.

Michael Willis wrote:What's your opinion about DPF, which allows a single project to be built as both LV2 and VST2? When I was getting ready to develop Dragonfly Reverb, I investigated Juce, DPF, and maybe some other frameworks that I've forgotten. I gave up on Juce when I was following the instructions and found that I needed to install some kind of custom IDE, the whole thing just seemed way more heavyweight than I wanted. With DPF it was really easy to just copy one of the example projects and start hacking. Admittedly, DPF has very simplistic GUI facilities, but in my minimalist opinion that was an advantage.

I think DPF is very good (and so is Dplug), however using straight LV2 can be very useful. LVTK offers a nice C++ wrapper around LV2.

I'm thinking about something like LV2 + OSC (liblo) + QML to write modern, efficient, portable and time-proof plugins without relying on plugin frameworks, I'd like to hear some opinions on this setup please!

SpotlightKid wrote: When we did a small plugin development workshop at our local Open Source audio meetup, we also used DPF: https://github.com/osamc-lv2-workshop/lv2-workshop

This is an awesome resource, thank you!

Hey, I just wanna say this, I would select lv2 support only if all host supported it. Renoise for example don't have lv2. I would love to use lv2 format only but host don't support it. We can't just make lv2 plugins if there is no hosts that runs it. I think the way is to make hosts support it first. And how would you do that? on all operating systems? vst is still the way to go if you want others to be able to use it

If you use a plugin development framework like DPF you can output several plugin formats from the same source, so can support VST and LV2. No need to decide for one or the other.

marbangens wrote:Hey, I just wanna say this, I would select lv2 support only if all host supported it. Renoise for example don't have lv2. I would love to use lv2 format only but host don't support it. We can't just make lv2 plugins if there is no hosts that runs it. I think the way is to make hosts support it first. And how would you do that? on all operating systems? vst is still the way to go if you want others to be able to use it

Well, but it's Renoise's own choice, LV2 is an open standard and the main implementation is released under the permissive ISC license. Is dragging down a whole community because some proprietary vendors decide to ignore a well established standard fair?

marbangens wrote:Hey, I just wanna say this, I would select lv2 support only if all host supported it. Renoise for example don't have lv2. I would love to use lv2 format only but host don't support it. We can't just make lv2 plugins if there is no hosts that runs it. I think the way is to make hosts support it first. And how would you do that? on all operating systems? vst is still the way to go if you want others to be able to use it

Interesting, that Renoise has DSSI and LADSPA support. Tracktion has LADSPA (due JUCE capabilities).
BTW, can anyone name good LV2-only synth for example? except Yoshimi of course

Most synths are either VST only or support both VST and LV2. But there are a lot of excellent effects, which are LV2 only.

But does that really matter? We have Carla, so you can use LV2 in a VST-only host and vice-versa. And, as I said above, developers can easily choose to support both formats. Can we concentrate on the original intent of the topic, that is, creating a LV2 plugin development guide?

SpotlightKid wrote:Most synths are either VST only or support both VST and LV2. But there are a lot of excellent effects, which are LV2 only.

But does that really matter? We have Carla, so you can use LV2 in a VST-only host and vice-versa. And, as I said above, developers can easily choose to support both formats. Can we concentrate on the original intent of the topic, that is, creating a LV2 plugin development guide?

Thanks for returning in-topic, however I wanted to stress that I don't think developers can legally* support VST2 anymore! That's part of the reason I wrote this post.

Basically, Steinberg/Yamaha officially discontinued it (official announcement here) and there's no way to legally redistribute it, and if someone does they rightfully get DMCA'ed.

As you say, some frameworks can legally build VST plugins (by using custom headers, I assume) but they are basically keeping alive an extinct format, and I don't think that's a good thing in the long run...

* I am not a lawyer but I am pretty sure that in the EU you can safely reimplement VST via reverse engineering, but I'm not sure about the US after Oracle v Google

Well, sorry for little off-top. But I must advertise that the Surge received LV2 just today.