Hi guys,
all the new features look super cool but there’s one thing missing in the linux version - LV2 support 
2 Likes
I was hoping for LV2 support so much… 
1 Like
Agreed, though pretty much all lv2 plugins i’ve come across also exist as either vst or dssi.
Yup but some of them are not updated as LV2 are and they don’t have super cool GUIs 
+1
It’s about time. Honestly, I wouldn’t even mind if they dropped ladspa/dssi/vst support in favor of lv2.
I wished one of the devs could at least giveus some piece of information about the state of lv2 support for renoise…
Pretty much all?
What about CALF, Guitarix, some of LinuxDSP’s plugins, DrumGizmo, IR.LV2 etc. etc.
Having to do without the CALF plugin suite alone is a really big letdown of using renoise.
Plus, the Steinberg patents make it really hard for developers to make thoroughly free plugins and to distribute linux-vsts freely via package managers etc.
I wonder, what’s the big technical problem with LV2 anyway? Ardour seems to be the only DAW right now that really supports LV2…
1 Like
I seems very few people actually care, which is probably one of the reasons why the devs are ignoring lv2. I still hope the considerations for lv2 support don’t go by the board as quickly as this thread
I hear you. I understand you.
I did use Linux for a very long time, started out in 1998. As much as I loved it I got sick of trying to get plugins and music software working with emulations and what not.
I bought Renoise because of it being the best available music making software for Linux. But as soon as I figured I’d need to stay with native DSPs only I got myself a Mac. Best of both worlds - Good software support, stable and it’s based on FreeBSD so the terminal is near.
Hopefully there will be lv2 support for you guys some day, but as with many wanted features it might take some time.
Cheers
Yes LV2 support is really needed! I actually hoped it will be in 3.0…
1 Like
Actually started working on this (kRAkEn/gORe did - have to thank him) but didn’t managed to finish it for r3. We also will not be able to get it done during the beta, but will of course try to add it to one of the upcoming releases.
This took so long, because as great and widely used LV2 is on Linux now, it’s pretty difficult to implement for us as closed software because of its dependencies to various other software technologies like turtle RDF, support for many different GUI frameworks and so on.
1 Like
Thank you for giving us a comment on this, taktik. And thanks for the effort, kRAkEn/gORe. This actually sounds quite promising and I keep my fingers crossed that you get it to work soon. I somehow feared that GPL/licence issues might be a problem but I’m sure you can get it done. LV2 will not be able to survive as a plugin-standard for linux if they don’t figure out how to let proprietary software implement it properly, too.
As for the technical difficulties, maybe you can take a look at Ardour/Harrison Mixbus and see how they managed to implement it.
1 Like
I somehow understood it was more a technical issue regarding 3rd party options/library that LV2 depends on as well and at which Renoise developers can have almost no or little influence on.
Which means that if something changes in those libraries, it could easily break LV2 support. But if that is fixed, it could as well require update of the software that supports LV2. (knowing that backwards compatibility is something that does not seem to exist in the developer world of Linux this quite often happens)
If your software is open source:everybody could theoretically adjust changes in the Lv2 specifications that would break the current or older LV2 specifications in your software whereas with closed source software: only the dedicated developers can and usually there is a lower release cycle on closed source software than with open source software. This is what really sucks the most about Linux for closed source developers and the userbase that depends on the release cycle in generic. And before i forget there is still this regular Linux habit called “dropping architectures and standards” that were a PITA to build support for in the first place. All of this amongst others is why you don’t see many closed source developers making the step to Linux because maintenance is a PITA if you also have other platforms to attend to.
LV2 is a mess. No documentation, no guidelines on how to implement features, mass of extensions that practically do quite the same thing just with small differences and that freedom allow developers to just “fork” extensions on their own plugin that must be supported explicitly by the host: this turn to be a bitch to maintain in the long run as new and modified extensions will grow and change and get deprecated over time and we developers of the host must keep adding and changing support for those new “methods” for doing the same things over and over again while keeping support for the old ones to not break compatibility with older plugins. Wicked !
Maybe from a plugin developer is a better standard, you choose some extensions your plugin will support and that’s it. From a host developer is quite the opposite. I need to check every plugin out there which kind of stuff he need to be supported and start hacking until i get it working (a cool way of developing indeed!).
And not speaking about the bloat: take for example sending midi to plugins. First there were the “event” extension (some plugins use it) but it was limited and got changed to the “midi” extension (other plugs use this), but hey the developers started to think communicating via an abstract “midi” protocol from the host to the plugin was not sufficiently generalized so the “atom” extension was born. All this means in the midi handler code i need to convert the events for the plugins in 3 different ways, thus bloating the code and maintainability by the size of 3. And everyone keeps using the extension they like most, without following any guidelines (are there any out there ?). Presets are the same, the “patch”, “state”, “preset”, “programs” extensions are available and do similar things (if not the same) and all must be supported by the host to be sure all plugins will work when changing presets…
Implementing UIs, on the other side is quite “straightforward”. Instead of abstracting and keeping things simple, support has to be given explicitly to each framework (qt, gtk, x11) also forcing to link to those frameworks (or make small external programs that link to the framework to avoid the main app to be linked with those), there are even custom extensions that try to mimic the DSSI behaviour cause other developers thought that DSSI ui was easy to support (after all everyone say shit about DSSI but in the end people come back to simplicity when simplicity means a better implementation).
What is done:
- all plugs load and emit sounds
- event handling (synthesizers) work
- plugs that support basic presets work
- basic ui work (renoise internal)
What is not done:
- sending timecode to plugin is not supported
- plugin ui support is not present
- plugins that need threaded background worker are not supported (maybe some IR plugin out there need this, i haven’t investigated)
Btw, as taktik said we will not be able to deliver lv2 support in 3.0, but will be available in one of the upcoming releases.
I don’t really understand your logic here. I have never seen any open source (or closed source) project to actually change things in an already released version of their product. Released is released. So what is the problem? If Renoise relies on “some package” version 0.5.2 than it will always work with this version.
What you think “sucks the most” about Linux is actually what is one of the best things about it. A windows programmer would just package all the dependencies he wants me to use with his own application, resulting in an immense redundancy of installed packages on my system…
So basically you are saying that the LV2 standard is actually no standard at all? That is a pity indeed. Thanks for the information, I wasn’t aware of this. Let’s hope the maintainers of LV2 will finally decide on a standard, otherwise LV2 will probably not last very long.
it’s a simple standard (namely the “core” is nothing more than LADSPA) but extensible by the so called “extensions”.
the problem is that extensions are far to be perfect and sometimes they get rewritten over time to support more features thus their numbers is growing; sometimes plugin developers does not support the lv2 core provided extensions and support “third party” ones: think the new “external ui” extension that makes the UBER MEGA LV2 uis as stated and sold everywhere practically a mimic of the DSSI standard… http://kxstudio.sourceforge.net/ns/lv2ext/external-ui
It’s a standard so extensible and free that people have copied the old method because it was better. Don’t say LV2 uis are better than DSSI ones, technically speaking the ones that makes use of the “external ui” are exactly the same thing, same problems same behaviour.
I see…and there is no guideline, or suggestion of what a modern host is supposed to support? In doubt, I would just support whatever the others support (take for instance Ardour as a guideline).
everything. that’s cool 
Well, maybe this is a little naive and just a dirty solution, but would it help to narrow down the number of officially supported lv2s to a list of those that people in the renoise community consider usefull for their work and leave out all the others for now? So you don’t have to put a lot of effort into supporting plugins that nobody is likely to ever use?
Hats off for you guys, i would really not spend my time on such kind of architectures because that is purely a waste of time. (seriously)
If Linux is the only thing i would program for, perhaps it would be worth the trouble but not if it would be just another platform that had to run my port.
Kraken just explained this logic perfectly in detail what i quoted above (it was my guess and he describes the situation being worse than i guessed).
In short: You release software today that supports the protocol / convention or standard reasonably well to very good and two three days later you can start add and change stuff again because the recent updated plugins and solutions no longer work.
You have to consequently monitor the CVS repositories of al these projects to see if nothing crucial is changed that would break your main support for the protocol. (that is if you know the protocol well and don’t need background information to get stuff working)
Pure waste of time.
Then you just use the previous version of that plugin which worked. Again, I don’t see the problem.
Reading this again, it seems that you do not understand how open source projects work…
But you would rather update because of the so many kick-ass new features that the updated version has or that annoying crash bug that had been finally resolved
I was just speaking of the basic opportunities here regardless of CVS access, project team assemblies, agreements etc… I know it is not regular that just everybody can touch the central code and replace it in the CVS, but theoretically everybody can download, modify and recompile the archived source code (which is usually available) on his/her own computer and have a solution now if adjustments are required. (not everybody is a programmer, but i was speaking theoretically)
Nobody can download any source code pack of Renoise and do a quick adjustment for recompilation, thus all Renoise users will have to sit and wait until it appears with a solution.
The same development team also have to take care that their implemented solution still works when Renoise is finally released because meanwhile things may have changed again that would have required internal updates of the code.