LV2 support

[umlaeute]

for a cross-platform environment, it would be great if juce could include LV2 as supported audio plugins.

see https://forum.juce.com/t/juce-lv2-plugin-wrapper/14209 for a discussion on this.

[simonvanderveldt]

Since the topic on the forums has been quiet for a long time as well, is there anything that can be done to get/keep this going?

[falkTX]

FWIW I've updated my juce fork to v5.1 juce sources.
See https://github.com/DISTRHO/juce

I think adding LV2 stuff in Projucer would not be too hard, but some confirmation about a possible merge (or not) would be great...

[mzuther]

+1

I've released two LV2 plug-ins based on falkTX's code almost five years ago and have used them extensively over the years. There wasn't any problem at all. Nothing.

My idea: add LV2 support to JUCE and mark it as experimental. Then watch if people start using it (I bet they will because moving over from VST is super-simple). If so, officially support it. Otherwise, just move it along. From what I've seen falkTX do, the amount of work for updating to future JUCE versions should be pretty small.

Just my two cents. :)

[gminorcoles]

Please

[fpesari]

Hello, still no news on this front, despite @falkTX contribution?

Too bad, it would be huge because even if VST3 is now under the GPLv3, no major free DAW (such as Ardour) supports it yet.

If JUCE has an advantage over other toolkits, it's its support for GNU/Linux. And it happens that right now, the most supported format for GNU/Linux audio plugins is LV2. So I think it would really be for the best if JUCE supported it, if only to increase adoption of JUCE among GNU/Linux audio developers.

[falkTX]

if only to increase adoption of JUCE among GNU/Linux audio developers.

That is not something that is going to help a lot tbh, since Linux audio devs are generally more conscious about privacy issues and Juce is quite aggressive towards user data tracking.
There is a general dislike of Juce within the Linux audio developer community because of its past behaviour. For example https://forum.juce.com/t/announcing-a-new-analytics-module/24764

Due to Juce not caring about LV2, user privacy, opensource models (if you look at their "get juce" page you will not be aware that free & opensource is an option) and other issues... Linux and opensource devs have been moving away from Juce.
I personally made my own little framework after being fed up with Juce, https://github.com/DISTRHO/DPF

and btw, dplug added LV2 support recently
there is a WIP branch for LV2 support in WDL
Juce might end up being one of the latest frameworks to support LV2 if we continue at this pace, even though it had ready-to-go LV2 support from the community many years ago... (I forgot how long this was now, but more than 5 years for sure)

[fpesari]

if only to increase adoption of JUCE among GNU/Linux audio developers.

That is not something that is going to help a lot tbh, since Linux audio devs are generally more conscious about privacy issues and Juce is quite aggressive towards user data tracking.
There is a general dislike of Juce within the Linux audio developer community because of its past behaviour. For example https://forum.juce.com/t/announcing-a-new-analytics-module/24764

Well, it's under the GPLv3 so that functionality can easily be stripped away when packaging for distros like Debian! 😉

I think that your effort with DPF is commendable @falkTX (like most things you do, I use a lot of code you wrote, thank you 😃) but there are a lot of free plugins around which use JUCE and porting them can be hard and time-consuming, while LV2 support would allow people without programming skills to build them easily.

This could also be useful for commercial purposes to ROLI, since LV2 is widely supported on GNU/Linux compared to VST3, for example. I don't know if your code can still be merged (many years passed) but it could be a starting point, perhaps.

[falkTX]

there is no need for hostility here.
just because you disagree with them, it does not give you the right to be rude to them, no matter how stupid you might think their actions are.

please delete your comment, or at least make something that is constructive.

[sadko4u]

please delete your comment, or at least make something that is constructive.

Alright. The issue is already hanging for more than two years without any reaction from the official developers/maintainers here, I think that they don't care about OSS developers and users at all because LV2 is now a main plugin standard for Linux/BSD-based systems.
Then, why should OSS developers care about the JUCE framework and their developers?

@falkTX you've offered a patch, you've did a lot of job that just should be merged into main tree. And... No reaction. Moreover, if applied, the result of your work will then be sold as a commercial solution for those who use JUCE as commercial framework. Any royalties to you? Don't even hope.

So, please, anyway, let the developers and maintainers of JUCE rest in piss!

[falkTX]

I never expected royalties from this, if that was not obvious before.
Just getting it out there and having more developers publishing LV2 plugins is enough for me.

oh 2 years does not cover how long it has been really.
the juce lv2 wrapper started before JUCE got bought by ROLI, back when JUCE was GPLv2+ and sourceforge was still relevant. Back then the forum was still some phpbb thing 😂

for curiosity sake I went to see how long it has been...
See https://repo.or.cz/juce-lv2.git, it is more than 8 years old! 😅

The way I see things, JUCE has become just like Android - it is used a lot and can be quite useful, but its leadership and past practices make it something you use not because you want, but because there are not many other options out there. It makes it unwanted for anyone that takes privacy and user freedom seriously, like yourself.

But what can we do?
The more noise we make here is probably just going to make them NOT want support LV2 at all.

JUCE has turned into a business, so its development and new features come from whatever the "business" needs.
LV2 is not profitable from the get-go, it is a long term thing, and a bet on their side in way.
Unless big names demand LV2 support, this ticket will go nowhere. That is just how JUCE operates right now, for better or worse.

I already lost hopes of this being an official thing.

[fpesari]

Hey @sadko4u, while I appreciate that you care about the issue (also, thanks for lsp-plugins, they are pretty nice!), there is no need to attack the JUCE developers. This can only make them think supporting LV2 is something undesirable, not the contrary. Please, edit the final part of your last post, let's try to be reasonable, even from a commercial standpoint.

Right now JUCE has many advantages over its competitors, but the biggest probably is its support for GNU/Linux. So:

1. Not being able to build plugins for the most popular format there is going to harm JUCE's multi-platform capabilities in the long run, it should be their interest to support LV2
2. People from the community would work on it for free, and this would spread the overall adoption of JUCE
3. If more people use JUCE, even under the GPL, it gets JUCE's name out there: it's free marketing, and good PR for ROLI

I'd like to hear someone from ROLI on this. I think we might come up with a solution, a common ground. Otherwise the community could fork the GPL version of JUCE and have that be version packaged in distros. We've already seen that free and open source software can be profitable, there's a reason even Microsoft releases tons of free/open source stuff, when it seems to be apparently against their interest.

[julianstorer]

We realise it’s frustrating when there a feature you care about doesn't seem to be on our radar! But this is a big and diverse library, and it's easy to lose sight of the fact that what matters to one person isn't necessarily important to the wider community.

JUCE has turned into a business, so its development and new features come from whatever the "business" needs.

JUCE has ALWAYS been a commercial product, and obviously we prioritise things that will benefit the most people, because more happy users = more commercial success.

Nowadays we prioritise features based mainly on the results of our user surveys. But just because there's some passionate interest displayed about LV2 on the forum and in this thread, in our surveys it scored incredibly poorly compared to things like improving the graphics performance, so right now that's where most of our energy is going. If we had a bigger team, we'd all love to see LV2 (and many other things!) get added, but that's not the reality right now.

In fact, it's particularly annoying to be criticised for not supporting Linux right now because we've recently over-spent in terms of the time we've put into Linux features. We have linux VST3 support almost complete (this was far more highly requested than LV2). That'll be released in the next version of JUCE. Ed has spent weeks making improvements to the linux event loop and other deep refactoring of the X windows system to help with plugins running in headless environments, and this ended up being much harder and time-consuming than we expected.

It is NOT just a case of accepting a merge request. When something becomes part of JUCE it must be maintained to the same high degree as the rest of the codebase. The changes need to be picked though line by line (and probably re-written - it’s extremely rare that any code from someone outside of the JUCE team doesn’t need a substantial re-write) and going forward it'll be our team who has to keep it working when the operating systems and other factors change. The idea that "the community will maintain it" is a total myth in our experience - we've tried that in the past but it never worked out.

[fpesari]

Thank you for your answer, @julianstorer 😺 👍

We realise it’s frustrating when there a feature you care about doesn't seem to be on our radar! But this is a big and diverse library, and it's easy to lose sight of the fact that what matters to one person isn't necessarily important to the wider community.

Well, one person here is actually 26 person(s) who have +1'd this issue! 🤣

Them or someone they have business or personal relations with could actually be paying JUCE users, or they work for a company which could be interested in JUCE.

In fact, it's particularly annoying to be criticised for not supporting Linux right now because we've recently over-spent in terms of the time we've put into Linux features. We have linux VST3 support almost complete [...]

I did not accuse JUCE of not supporting Linux (Edit: in the previous message, I actually said its support for GNU/Linux is its biggest advantage over its competitors), I said that without LV2, Linux support can only be partial since VST3 is not supported by any free and open source Linux DAWs or even standalone host.

I tried building VST3 myself and I got a segfault when trying to run one of the shipped examples on Debian - it's not as production ready for GNU/Linux as LV2 is, in my opinion. This isn't JUCE's fault, and with VST3 being licensed under the GPL, it's just as good as having LV2 support, from a purely philosophical perspective - just not a practical one. We're not being idealists here, we're being practical 😃

The idea that "the community will maintain it" is a total myth in our experience - we've tried that in the past but it never worked out.

Let me be clear about this: I, as a (potential) user of the GPL version of JUCE, do not have any right to ask anything of ROLI. I apologize if I gave the impression of being entitled.

You're trying to do your job to feed yourself and some people who probably won't ever spend a dime on JUCE come here and complain about things that don't even exist in the professional audio world, bringing negativity and bad PR.

Things like these turn off commercial developers from releasing free and open source programs, they are awful, if you think this, I agree.

But over the years, with all the experience with Red Hat, SUSE, Ubuntu, the Linux kernel, Qt, etc., we should all have learned to deal with these issues in a peaceful way, through dialogue, collaboration and reciprocal understanding.

I understand, supporting and maintaining code has a cost. But you are not morally or legally obliged to provide support for the LV2 part of JUCE, that would be unreasonable, and nobody here is asking for it. You could simply not support it officially or label it as experimental and unsupported.

Maybe the community won't take care of it, maybe yes, you could disable it in the default build and ask users to set a manual flag or not ship it at all in the commercial version of JUCE.

And I know that even in this case, you will get issues here on Github about that LV2 port, which will bring more people complaining if these issues are not dealt with, and so on. But those people would entitled people who have no right to say those things, and ROLI could not get bad publicity for refusing to support a feature that they don't have to support.

We don't have to be "us vs them", or "free/open source vs commercial" or "users vs devs" or whatever. We can find a common solution, since JUCE is GPL we both benefit from it being better and more widespread, there is no need to harm your livelihood.

I am fairly sure that paying JUCE customers won't drop it if supports LV2, I think we can all agree on that. It can only improve JUCE's adoption, even if it's officially unsupported. Maybe we can find a way to fund this effort, if necessary, or the community could hire an external dev to work on it, but then it would be useless if the code isn't merged.

[umlaeute]

@mfisher how is that related to the problem at hand?
please don't abuse this issue tracker for promotion of your own projects (however laudable your project might be)

[mfisher31]

@umlaeute Jules made it clear they aren't going to support LV2 any time soon. I offered an alternate solution to @falkTX 's fork. @julianstorer feel free to delete my comment if you believe I am just self promoting.

[mfisher31]

Actually, nevermind. If that's how my comment is perceived, then I'll gladly remove it myself.

[mxmilkiib]

https://github.com/lvtk/jlv2 - "LV2 Related JUCE Modules", directly related because it's a practical form of workaround to this unresolved issue.

[mxmilkiib]

Further to the LV2-supporting DISTRHO/juce fork, there is the lv2-porting-project/JUCE.

[JPenuchot]

Hey, Radium devs are waiting for LV2 support in JUCE just so you know (still very actively developed DAW, has 400+ stars on GitHub, pd & faust built-in, etc.). Most audio plugins available on Linux aren't available on it because that feature is currently held back

kmatheussen/radium#121

[falkTX]

Just FYI to people here, I have updated my juce fork for LV2 support (and some small other fixes)
Again, at https://github.com/DISTRHO/JUCE
Can be used as a drop-in replacement of upstream JUCE.
My fork is at 6.0.4 at the moment, with a few small patches from JUCE develop branch.

The list of patches not applied upstream is cleanly available at
https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/juce-current/patches

ProJucer support for LV2 is still not implemented, since I do not use that myself.
If anyone is interested on doing that part, please let me know, we can work together on it.

[JPenuchot]

Great work! Do you plan to open a pull request to merge that into upstream JUCE?

[falkTX]

Great work! Do you plan to open a pull request to merge that into upstream JUCE?

JUCE devs already said in this very thread that they are not interested on LV2, this is why I keep the fork active and maintained.
Also, JUCE never applies a pull request directly, they always reimplement.

[fpesari]

JUCE devs already said in this very thread that they are not interested on LV2, this is why I keep the fork active and maintained.

Is this also true after the PACE acquisition?

[mfisher31]

Is this also true after the PACE acquisition?

Wouldn't expect official support any time soon. best to just use @falkTX 's fork.