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).
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)
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.
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?
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.
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.
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…
