Not that I know of, but it's a brilliant idea. I've been meaning to setup some kind of wiki based thing where users can share problems/experiences, but just never had the time.

That gives me a thought. Please excuse me if the following sounds like it's too central management-based, and it may well be that. But if we as a community would take more responsibility for managing plugin sets written for specific purposes, perhaps we could reduce duplication of work and help people concentrate on shared codebases. I'm not suggesting that individually written, "external" plugins and plugin sets should be considered fringe material, let alone shunned. But seeing how the Linux kernel community works, I think that creating something like "The Linuxaudio.org Plugin Collection" could benefit a common purpose. There could be separate sets for filters, delays, reverbs, oscillators, etc, all being individual parts of a larger common code repository. And individual ("external") developers could actively campaign for the inclusion of their plugins and/or code refinements to the said plugin sets. Additionally, the linuxaudio.org plugin set developers could keep an eye on new and promising plugins, and approach their developers in hopes of gaining new contributions. Of course the whole purpose of such a centrally managed plugin repository would be to give birth to Very Good Code. That implies that any contributions would need to adhere to accepted common standards and practices, just like contributions to the Linux kernel need to adhere to the standards and practices of the kernel community. Juuso _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

On Wednesday 05 September 2007 11:16:42 Georg Holzmann wrote: In my optimistic vision, the authors of some respected existing plugin collections would decide to join forces and set up a common playground. But things may not always work according to one's wishes -- especially if he isn't a plugin author himself... Are there any such authors listening who could share their thoughts?

I assume you're imagining that the plugins would be copied to the common repositories as-is; please correct me if I'm wrong. In my mind this new codebase, although built upon existing code, would be like any other new plugin collection with new, individual names and everything else that goes with it. Many of the existing plugin collections would become abandoned by necessity, as work would be focused towards a common project, but none of the new plugins would conflict with the old ones. So package managers (myself included) wouldn't really have to worry. Some older plugin sets would of course become redundant as the new common collection would initially introduce much of the same stuff in new clothes. But I want to stress the word _initially_ here, because from there on the efforts would be much better concentrated than before.

yep. maybe the gstreamer way is a possible solutions, or something similar. they have three categories: good, bad and ugly (which are also different packages): -------8<-------- gst-plugins-good: a set of good-quality plug-ins under our preferred license, LGPL gst-plugins-ugly: a set of good-quality plug-ins that might pose distribution problems gst-plugins-bad: a set of plug-ins that need more quality --------8<-------- (http://gstreamer.freedesktop.org/modules/) So I think a common SVN/CVS repository for LADSPA plugins would be nice, if all authors would agree on that and would manage their code within that.

2007/9/6, elthariel &lt;elthariel(a)gmail.com&gt;om>: Hi all, what about setting up an Internet service to find, download and install plugins directly from audio applications?

Maybe a library can be developed to do this, containing all the needed stuff to properly interface with the packaging system of each distro/OS (or in case there aren't any, download the source and tell the user to compile it) and maybe also downloading the packages directly from the repository of the given distro (or the official source tarballs). What do you think about it? Is it feasible? Just my 2 cents. Stefano _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev

I am working on a site zzub.org which might feature binary downloads of Ladspa plugins for windows, and on linux once it gets into a fashionable state. But I would love to learn what meta-data would be required for each binary version on the server so that a client would be able to determine what version would work on your OS/Distro.

2007/9/13, Stefano D'Angelo &lt;zanga.mail(a)gmail.com&gt;om>: 2007/9/13, Benjamin Bruheim &lt;grolgh(a)gmail.com&gt;om>: would I'd say package format (.rpm, .deb, etc), OS distribution (Ubuntu, OpenSUSE, etc.), CPU architecture (ix86, x86_64, etc.) and maybe binary format (ELF, .dll, etc.). I guess a description wouldn't hurt too. Personally, I'd like to see also some categorization stuff, user comments, votes, demos and so on. This is planned, i'm currently working on it. I think the packaging problem should be handled by the library who access the repository through a webservice. I think binary form, event with its disavantadge is easier for the musician :/

On Thu, 2007-09-13 at 14:41 +0100, Steve Harris wrote: The easiest thing would probably be to have a library that calls some sort of internet service that maps (plugin ID, platform) to a package name, for example ("LADSPA:1198", "Debian/Etch/amd64") -> "swh-plugins". Then the package swh-plugins can be installed, automatically if desired, using the normal distribution tools (e.g. 'aptitude install swh-plugins' in this case).

yep. maybe the gstreamer way is a possible solutions, or something similar. they have three categories: good, bad and ugly (which are also different packages): -------8<-------- gst-plugins-good: a set of good-quality plug-ins under our preferred license, LGPL gst-plugins-ugly: a set of good-quality plug-ins that might pose distribution problems gst-plugins-bad: a set of plug-ins that need more quality --------8<-------- (http://gstreamer.freedesktop.org/modules/)

SVN is one (good) thing, but pre-packaging is very bad. Who will decide whats good and whats not? There is no indipendent way for all styles of music. Whats good for electro is bad for classical and so on. So prefiltering is not the right way. Reviewing afterwards regarding to cases of use is a more fair system.

Does anyone actually use packaged versions of LADSPA plugins? Every time I've tried to do so, the old versions available in packages would not compile on my platform, or had fatal stability issues, or were not available, or were missing components.

That gives me a thought. Please excuse me if the following sounds like it's too central management-based, and it may well be that. But if we as a community would take more responsibility for managing plugin sets written for specific purposes, perhaps we could reduce duplication of work and help people concentrate on shared codebases. I'm not suggesting that individually written, "external" plugins and plugin sets should be considered fringe material, let alone shunned. But seeing how the Linux kernel community works, I think that creating something like "The Linuxaudio.org Plugin Collection" could benefit a common purpose. There could be separate sets for filters, delays, reverbs, oscillators, etc, all being individual parts of a larger common code repository. And individual ("external") developers could actively campaign for the inclusion of their plugins and/or code refinements to the said plugin sets. Additionally, the linuxaudio.org plugin set developers could keep an eye on new and promising plugins, and approach their developers in hopes of gaining new contributions. Of course the whole purpose of such a centrally managed plugin repository would be to give birth to Very Good Code. That implies that any contributions would need to adhere to accepted common standards and practices, just like contributions to the Linux kernel need to adhere to the standards and practices of the kernel community. Juuso