Yes, I agree. This is and always has been a downside of closed source software. Thus, the best thing you can do is to use the version with which it works. Once Renoise developers decide to release a new version, I hope they will include the state of the art standard at the time of release. This is not optional of course, I agree, but it is just a given limitation of closed source projects as you have correctly described.
Maybe a better idea to implement native modular synth building blocks, so Renoise users can make their own synths and Linux users don’t have to rely on a hackathon standard?
Thanks for that! Linux… kind of love & hate relationship 
I highly appreciate the trouble you’re going through. As a user I can’t wait for lv2 support.
Interesting indeed.
This is completely wrong. The MIDI extension defines a type for a MIDI event, i.e. “this bunch of bytes is in MIDI format”. It dates from the time of the original event extension, was used as the MIDI type then, and is still used for the MIDI type with atoms. It is not the same kind of thing as the event and atom extensions at all. The second paragraph of the documentation (Missing Page) that apparently doesn’t exist explicitly says this.
That said, there are indeed two extensions for sending events to/from plugins, atom and event. Oops. Yes, this is mildly annoying for hosts to implement. Mildly annoying as in, a competent developer can implement support for both in less than 300 lines of C, like http://svn.drobilla.net/lad/trunk/jalv/src/lv2_evbuf.h and http://svn.drobilla.net/lad/trunk/jalv/src/lv2_evbuf.c.
If even that’s too much work and you don’t want to support the old one… then don’t.
… writing a fully featured portable toolkit for plugin GUIs is, obviously, dramatically more complicated than just letting developers expose whatever types of widget they want. The UI extension is extremely simple. While it would certainly be nice if a more unified solution was there, it’s not the place of the LV2 project to be ramming toolkits down people’s throats. The suil library makes it easy to embed any of the popular choices in (Gtk or Qt, so far) hosts, so it’s not really much of a problem anyway.
If you want some dictatorial company to tell you what you’re allowed to do, by all means, stick to VST or whatever. Those of us actually working on pushing the envelope of what is possible with plugins quite like the extensibility, thanks. Nobody says you have to support everything.
The DSSI version then?
Yes: don’t implement deprecated extensions in new code. The event extension has had big orange all-caps DEPRECATED warnings on it for almost two years now, almost all plugins have moved on, and it will not be long before even hosts that already support both start dropping support for the deprecated event extension and forcing plugins to catch up.
I don’t recommend wasting your time on the (unofficial) external UI extension, either. External UIs suck.
Renoise has more than enough clout as a host to put pressure on plugins (most of which have much more agile release cycles) to shape up.
As always, the folks on the lv2-dev mailing list would have been happy to clarify any of this, had anyone bothered to ask.
Which is the place where any particular “uniform standard” in any type of architecture is actually designed and set (aside from the Linux kernel development) on a more global scale?
At least they know how to set a standard and update to new standards that remain backward compatible so we don’t remain stuck with ruins of deprecated architectures of which it is also quite usual to abandon them and let them decline before the end of the year.
Avoiding design of global standards (if that is the generic spirit in the open source world) just to rebel against multinational institutes because they are considered the root of all evil seems just foolish to me imho.
The generic idea of ever evolving software technology is nice for a world where you don’t need warranties that todays tools will still work the same tomorrow because you also don’t have to pay a dime for it. But it has no use to put up such remarks towards developers that deliver their product on a payroll. These are simply just too different worlds apart from each other to assume attitudes by comparison because you still can’t compare an open source world with a closed one. Developers bringing a payed product to an open source world by choice i consider a brave but painful endeavor.
People need to eat. One is better in plumbing and another is better in developing software, both deserve the credit for their living.
a good standard doesn’t need to have external helper libraries to ease it’s integration: so for me lv2,suil,serd,sord,sard,sick,sratom all togheter form a “standard”. without your helper libraries (which are not part of lv2 itself) hosting lv2 plugins is a tedious process.
i don’t want dictatorial company nor i want few dictatorial developers to tell me which kind of extensions are “officially” supported or not, and which directions the “standard” will follow. why the external ui cannot be part of the lv2 ? who choose, the community ? interesting discussion following at http://www.drumgizmo…o.log.25Aug2013
sure will do. probably a good open standard with directions should at least define deprecation policies and timelines.
so you say we should drop support to Calf, linuxDSP, Pianoteq, the DISTRHO ports and Rui Capela’s synthesizers. ok, so go on and speak to our customers we wont support those plugins. this is were pushing the envelope of what is possible with plugins has arrived, thanks for making it possible…
warning, another interesting interview follows http://libregraphics…pers-standpoint
Bumping up this thread: one year has passed, a new release of the Calf suite, and Redux is stealing all the thunder.
Any hope to get LV2 in Renoise at some point or will Redux in Ardour/Qtractor/whatever be the way to go?
Yes, please please please. I really hope it is in the up coming version bump but somehow I doubt it.
please <3
Check this out
1 Like
i have been using carla successfully with the issue of not being able use automation curves. it sais that it is experimental, does it still work reliably?
1 Like
It worked for me for many plugins but experimental means expect problems.I advise you to render the plugins to samples before saving the projects.
1 Like
It’s really odd to me that we have LADSPA and DSSI support, but not LV2.
Reaper got LV2 support last year and JUCE7 will come with LV2 support (both plugin + host) soon. Both of these are fully cross-platform btw! (there is really no reason to make such a feature Linux-only).
Implementing LV2 host support is even rather simple, as there is the liberally licensed lilv library that takes care of all the boilerplate. → GitHub - lv2/lilv: LV2 host library
2 Likes
We have clap now. Maybe this makes more sence
1 Like
Or maybe not. One does not exclude the other, either.
The fact that JUCE7 will have official support means that 90% of plugin developers will already have a very easy way to create LV2 plugins.
2 Likes