LV2 support about juce HOT 44 CLOSED

We’ve recently been investigating adding LV2 support for both hosts and clients to JUCE, and I feel confident that this feature will be included in an upcoming release. We don’t have a concrete timeline for this work, but hopefully the beta will be ready soon (i.e. months rather than years).

from juce.

Just in case anyone missed it, LV2 support is now available for testing on the juce7 technical preview branch.

from juce.

I can't give a firm date. The work is currently being reviewed by the team. Before making the work public, I'll need to correct any glaring issues that they find. That said, I believe that the bulk of the work is done, so I'm hoping to release a beta fairly soon.

from juce.

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

from juce.

+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. :)

from juce.

I would like to bring some attention and discussion to this again.

LV2 support is more widespread than it was some years ago.
Now we have Ardour, Carla, Element, Mixbus, Mixxx, Reaper, Zrythm (and maybe even more) that work cross-platform as plugin hosts.

The main reason that I am bumping this topic is because the current LV2 wrapper as exists today in my fork is quite outdated, and I would like to refactor and update it, matching latest JUCE developments.
I can give away the code for this completely free, CC0 / public domain or in whatever fashion you need to make it suitable for official juce inclusion.

Seeing as cmake is supported now, there is no need to add/modify ProJucer to support LV2 specific items, we can just add some rules around cmake.

JUCE has also changed a lot since a few years, Jules is not involved with it anymore as far as I know.
Can we please discuss this topic again in a serious manner? Thank you.

from juce.

Again, I can't commit to a specific timeframe at the moment. In the past, we've had public "preview branches" for large features (CMake support, accessibility) and I expect that we'll do something similar for LV2 as well.

from juce.

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.

from juce.

Understandable, just thinking of what can work best timing-wise.
I am willing to help push this forward.

Is it possible to have this be a more open process? Instead of the old regular surprise "code dump" when everything is done, with no one but the private/internal team with access to it. There is a lot of interest from the opensource community in having official JUCE and LV2, pretty much all LV2 hosts and plugins are opensource, would be great to collaborate on this.

from juce.

Not just Reaper, mixxx developers mentioned enabling lv2 for all platforms on their next release.

Audacity supports LV2 as well, though they only enable it on Linux.

from juce.

Now Reaper added LV2 support...

from juce.

All fair and reasonable. So why not just let in a few developers interested on the matter?
If code is released only when 99% ready there can be, for example, shortcomings on the implementation that you did not think of and having it needed to be redone.
You do not have to do it all alone.

from juce.

Thank you all for your input. It's nice to be able to close this off.

from juce.

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.

from juce.

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.

from juce.

At the moment, clients use new-style patch parameters, allowing the plugin (not the UI) to report parameter changes back to the host if necessary. The hosting code should understand both control ports and patch parameters.

from juce.

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.

from juce.

That is great to hear!

Any possibility of previewing the feature so it can be integrated into other products?
I am specially interested for MOD Devices / modgui integration, since this platform solely uses LV2 plugins (I work for them).
We already have a few JUCE based plugins on it, but everything still unofficial. We want to start developer onboarding and documentation very soon, would be great to have this ready and working side by side.

from juce.

Any update/schedule on when we may see a Beta of this @reuk ?

from juce.

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!

from juce.

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

from juce.

And now officially released! 🚀

Suggested to then close this topic and create new issues on any missing/incomplete/buggy implementation.

from juce.

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.

from juce.

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

from juce.

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?

from juce.

Please

from juce.

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.

from juce.

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)

from juce.

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.

from juce.

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.

from juce.

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.

from juce.

@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)

from juce.

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

from juce.

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

from juce.

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

from juce.

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

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

Is this also true after the PACE acquisition?

from juce.

Is this also true after the PACE acquisition?

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

from juce.

Although feedback from real-world usage is invaluable to us, releasing a feature while it still has known issues/shortcomings is not a good use of time. For the community, users may spend time reporting bugs that are already known to us, or release products that have bugs, incurring maintenance costs. On our side, maintaining an additional branch is time consuming and complicates bug-reporting (and rebasing this branch may break user submodules etc.), so we'd prefer to avoid preview branches that are too long-lived.

from juce.

No one is suggesting that we would wait for 99% completion. As @reuk suggested our current implementation has a fair number of areas we know need some work before it would be useful to share. None of the large missing pieces are particularly controversial.

from juce.

ok good enough then. we will just wait.

but one crucial thing to know - how are plugin parameters being handled? old style control ports or new style patch/parameter usage?

from juce.

Thnx for the info @reuk looking forward to that :)

from juce.

I was so pleased to return to this thread after a year and to see that LV2 support is on its way. Looking forward to trying it out!

from juce.

#664, port metadata and CV support, is one of the further issues

from juce.