[LAD] State of Plugin API's
Hi guys, I'm looking to delve into the world of plugins (for both synth and fx), and of the free API's I find LADSPA, DSSI, and LV2. But the picture is a little confusing. It appears that LV2 is "current," that DSSI is deprecated, and that LADSPA would be deprecated if it weren't so widely adopted. However, LV2 is slow in being adopted. Is this developer resistance... or is it just too new? Also, I can't find any applications that will host all 3, nor even LV2+DSSI. Is there a technical reason for this? Thanks in advance, Gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Wed, 28 Oct 2009 08:50:34 -0500 (CDT) "Gabriel M. Beddingfield" wrote: > > Hi guys, > > I'm looking to delve into the world of plugins (for both synth and > fx), and of the free API's I find LADSPA, DSSI, and LV2. But the > picture is a little confusing. Hey Gabriel, I'm no dev but I'll try to give you a reasonable complete picture of the situation. > It appears that LV2 is "current," that DSSI is deprecated, and that > LADSPA would be deprecated if it weren't so widely adopted. However, > LV2 is slow in being adopted. Is this developer resistance... or is > it just too new? LV2 is a very extensible standard, which means that the core does little, the extensions provide functionality (GUI as well as much more basic things). This allows it to become a very powerfull standard, in theory. The practical problems seem to be: Someone needs to write the extensions. The extensions need to be supported by hosts. So if you want functionality that's not yet there you need to write the extension and basically write a host that supports it or extend an existing host. For someone who just wants to write a plugin this can be a hurdle. Hosts are currently slow with adopting extensions. This leads to compatibility issues where any given plugin might only work in one host. It's especially a problem for users and will get more severe as the number of plugins, hosts and users increases. Afaik nothing has been done about this problem yet. > Also, I can't find any applications that will host all 3, nor even > LV2+DSSI. Is there a technical reason for this? > > Thanks in advance, > Gabriel Afaik there's no technical reason for this. Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
"Gabriel M. Beddingfield" writes: > Hi guys, > > I'm looking to delve into the world of plugins (for both synth and fx), > and of the free API's I find LADSPA, DSSI, and LV2. But the picture is a > little confusing. > > It appears that LV2 is "current," that DSSI is deprecated, and that LADSPA > would be deprecated if it weren't so widely adopted. However, LV2 is slow > in being adopted. Is this developer resistance... or is it just too new? I think both. > Also, I can't find any applications that will host all 3, nor even > LV2+DSSI. Is there a technical reason for this? No. OTOH naspro acts as wrapper that presents ladspa and dssi plugins in lv2 world. LV2 covers most if not all features of LADSPA and DSSI but LV2 still misses some important extensions (presets, binary state save/store) that makes it inferior when compared to well established stuff like VST. I think this is one of the reasons of low adoption. The other is that it is just too new (as in not enough plugins/hosts). As it is an open source community project and not driven by an enterprise, its development is slow when community is small and somewhat apathic. Other ppl involved in LV2 stuff may disagree of course. -- Nedko Arnaudov pgpsKZFdxo7Dj.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
Gabriel M. Beddingfield wrote: > Hi guys, > > I'm looking to delve into the world of plugins (for both synth and fx), > and of the free API's I find LADSPA, DSSI, and LV2. But the picture is a > little confusing. > > It appears that LV2 is "current," that DSSI is deprecated, and that LADSPA > would be deprecated if it weren't so widely adopted. However, LV2 is slow > in being adopted. Is this developer resistance... or is it just too new? as others pointed out, the extensions (while being good from a design POV) have actually hindered adoption. but general consensus seems to be that while lv2 might have some awkward aspects (not everyone likes RDF), it's the way to go. for a general strategy, can i suggest this: * if you are writing a signal processing plugin, target ardour2's set of extensions. if they are not sufficient, make your plugin so extremely good and your new extension so well-designed that the ardour devs can't afford not to add your extension. * for a synthesis plugin, target the most kickass synth environment you can find - i don't know what that could be, ingen comes to mind, but i've never used it and it may be stalled. others will be able to comment. in short, concentrate on hosts with a wide user base, and hope that necessary extensions become de-facto standards over time. to be very frank, i think the lv2 process showed that no matter how brilliant your design, if you fuck up the community engineering aspect, you're doomed. LADSPA could be implemented in minutes by a braindead zombie (hell, even yours truly managed to write a plugin or two), and see how people jumped at it - adoption rates were spectacular. compared to that, lv2 was a spectacular failure. let's take the lv2 technology, get a set of canonical extensions that every plugin author can expect to be present on every host worth its salt, and drag it to "critical mass" :) in the medium term, i think we should try to get an lv2 workshop going for LAC2010, and also have a BOF session on "canonical sets of extensions" for synthesis and processing environments. just my... jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
Hi All, On Wed, 28 Oct 2009, Nedko Arnaudov wrote: > > No. OTOH naspro acts as wrapper that presents ladspa and dssi plugins in > lv2 world. I didn't know about NASPRO. Thanks! And thanks to everyone who has (and will) comment. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
2009/10/28 Jörn Nettingsmeier : > let's take the lv2 technology, get a set of canonical extensions that > every plugin author can expect to be present on every host worth its > salt, and drag it to "critical mass" :) > Also there should be two full-packages: lv2-sdk(everything required to start development, including extensions and libs, slv2, docu, etc) lv2-plugins-all (the most used/recommendable, stable plugins, ready to run, incl. dependencies) Gathering the required packages and dependencies for plugins and hosts (with corresponding versions ! ) is a kind of detectiv work currently. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
Hi all, On Oct 28, 2009, at 8:59 AM, Jörn Nettingsmeier wrote: > Gabriel M. Beddingfield wrote: >> It appears that LV2 is "current," that DSSI is deprecated, and >> that LADSPA >> would be deprecated if it weren't so widely adopted. However, LV2 >> is slow >> in being adopted. Is this developer resistance... or is it just >> too new? > > as others pointed out, the [LV2] extensions (while being good from > a design > POV) have actually hindered adoption. but general consensus seems > to be > that while lv2 might have some awkward aspects (not everyone likes > RDF), > it's the way to go. Consensus? Right. I know of several talented linux audio developers who consider DSSI to be obsolete -AND- I also know of a similar number who have said they'll never use LV2. Recently I've seen more new open-source synth plugins being released as VSTi's than either LV2 or DSSI. GMPI doesn't exist, because people couldn't reach consensus. Sounds familiar. ALSA versus OSS vs PulseAudio vs JACK. C vs C++ vs . Emacs vs vi. XML vs everything else. They all suck, some just suck more than others -- and which suck the least depends on what you want to use them for. For simple effects, it does seem like LV2 may eventually supplant LADSPA. But for softsynths, I don't see any one of the current plugin APIs (LV2, DSSI, or VSTi) obsoleting the others any time, well, ever. There's just too much difference in personal tastes. My advice: write to the API that appeals to you most. The playing field is level and slow-changing enough at the present time that far more important than someone else's idea of what is "current" or "deprecated", is * what will feed your creativity and joy the most? * because no single API is ever going to please everybody, no one's going to pay you for your work, and only a fraction of those who use it will even take the time to say thank you. My point is, be clear about your motivation. Choose an API that fits your tastes. Then go create some killer plugins. I'm looking forward to trying them. ;-) -Sean ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Wed, 2009-10-28 at 16:59 +0100, Jörn Nettingsmeier wrote: > to be very frank, i think the lv2 process showed that no matter how > brilliant your design, if you fuck up the community engineering aspect, > you're doomed. LADSPA could be implemented in minutes by a braindead > zombie (hell, even yours truly managed to write a plugin or two), and > see how people jumped at it - adoption rates were spectacular. > compared to that, lv2 was a spectacular failure. Implementing an LV2 with the same capability is every bit as easy. Like many complaints about LV2, this really just amounts to whining that someone else hasn't done everything for you already. That's not a failure of community engineering, that's a shortage of time and people to actually do the work. This is hardly a new thing in LAD. There are simply not that many developers around, and things take time. LV2 now is a lot more powerful than LV2 when the spec first came out, and LV2 a year from now will be a lot more powerful than it is now. If you think LV2 "was" (?) a spectacular failure, you clearly aren't really paying attention. "Failure"? Why, exactly? The extension approach IS community engineering. It allows YOU, or anyone else, to actually do the work. A monolithic specification just results in an endless war on mailing lists, and allows NOBODY to actually do the work. (*** If you read nothing else in this email, read this ***) Blaming the mechanism for this is complete nonsense (and people trolling and spreading FUD by doing so has gotten /really/ old). This is exactly like blaming the shared library mechanism for the fact that there's no open source shared library to do realtime granular resynthesis, or whatever. Think about how absurd this is! Would you start sending emails to your OS distributor because there are no shared libraries for realtime granular resynthesis, because their "shared library" pie in the sky technology somehow prevented it from being done? Of course not, that's completely ridiculous! The mechanism is what makes it possible to implement such a thing. Does complaining about the shared library mechanism in this way sound really stupid? It should. Complaining about the LV2 extension mechanism for a lack of implemented extensions is exactly the same thing. The problem is simply that NOBODY HAS WRITTEN IT YET. Enough with the FUD, please. The only thing really lacking in terms of community/PR IMO is the website, which is static, stagnant, and not particularly good anyway. It should probably be nuked and either everything moved to the wiki, or replaced with a CMS. The former is easier since there's already a wiki, the latter is fancier and more professional looking. > let's take the lv2 technology, get a set of canonical extensions that > every plugin author can expect to be present on every host worth its > salt, and drag it to "critical mass" :) Let's indeed. Feel free to get started any time now ;) Though there's not really a need to try and do this "canonically". What's 'clearly necessary' for one plugin is completely useless for another. An extension is supported or it isn't, in the vast majority of cases the plugin/host can easily just not use if it isn't there. The only real potential problem is when multiple extensions get created for the same thing. As long as people cooperate (via the mailing list and/or wiki) and create high quality extensions this should not be a problem. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, Oct 31, 2009 at 12:08:54PM -0400, David Robillard wrote: > ... This is exactly > like blaming the shared library mechanism for the fact that there's no > open source shared library to do realtime granular resynthesis, or > whatever. It's very different. If I want to write a library to do realtime granular synthesis I don't have to extend the shared library mechanism first, or write a new dynamic linker. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, 2009-10-31 at 17:35 +0100, f...@kokkinizita.net wrote: > On Sat, Oct 31, 2009 at 12:08:54PM -0400, David Robillard wrote: > > > ... This is exactly > > like blaming the shared library mechanism for the fact that there's no > > open source shared library to do realtime granular resynthesis, or > > whatever. > > It's very different. If I want to write a library to do > realtime granular synthesis I don't have to extend the > shared library mechanism first, or write a new dynamic > linker. You don't need to extend the extension mechanism first (I don't even know what this means...) or write a new host either. Shared library, you get a thing by filename, it has code in it. Extension, you get a thing by URI, it has code in it. It is not "very different" at all. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, Oct 31, 2009 at 1:40 PM, David Robillard wrote: > On Sat, 2009-10-31 at 17:35 +0100, f...@kokkinizita.net wrote: >> On Sat, Oct 31, 2009 at 12:08:54PM -0400, David Robillard wrote: >> >> > ... This is exactly >> > like blaming the shared library mechanism for the fact that there's no >> > open source shared library to do realtime granular resynthesis, or >> > whatever. >> >> It's very different. If I want to write a library to do >> realtime granular synthesis I don't have to extend the >> shared library mechanism first, or write a new dynamic >> linker. > > You don't need to extend the extension mechanism first (I don't even > know what this means...) or write a new host either. > > Shared library, you get a thing by filename, it has code in it. > Extension, you get a thing by URI, it has code in it. > > It is not "very different" at all. that's just one side of the equation. having found the thing, what gets done with it? there are two things with a shared library: * run time linker gets it all nicely set up in the address space of the process * parts of the app call functions in the library API to get things done with an LV2 extension, what are the analogies? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, 2009-10-31 at 14:05 -0400, Paul Davis wrote: > On Sat, Oct 31, 2009 at 1:40 PM, David Robillard wrote: > > On Sat, 2009-10-31 at 17:35 +0100, f...@kokkinizita.net wrote: > >> On Sat, Oct 31, 2009 at 12:08:54PM -0400, David Robillard wrote: > >> > >> > ... This is exactly > >> > like blaming the shared library mechanism for the fact that there's no > >> > open source shared library to do realtime granular resynthesis, or > >> > whatever. > >> > >> It's very different. If I want to write a library to do > >> realtime granular synthesis I don't have to extend the > >> shared library mechanism first, or write a new dynamic > >> linker. > > > > You don't need to extend the extension mechanism first (I don't even > > know what this means...) or write a new host either. > > > > Shared library, you get a thing by filename, it has code in it. > > Extension, you get a thing by URI, it has code in it. > > > > It is not "very different" at all. > > that's just one side of the equation. > > having found the thing, what gets done with it? there are two things > with a shared library: There is a pervasive theme of people criticizing what they do not understand here. It is generally not wise to do that ;) > * run time linker gets it all nicely set up in the address space of > the process Free, since this is all (likely) taking place in memory anyway. > * parts of the app call functions in the library API to get things done Identical. There is no other side of the equation because the whole thing is so painfully simply. You get your pointer. Done. They are both literally just mechanisms to get a pointer to some code/data by name. It's really quite simple... I'm not sure where this conception that there's some kind of hard to understand complex mechanism involved here comes from, but there really isn't at all. "Mechanism" isn't even an appropriate word, really, it's just a function. It's as straightforward as straightforward can be. Look at the header: const void* (*extension_data)(const char * uri); This is the "extension mechanism" for plugins. You give it a URI, it gives you something back. That's it. Implementing, and calling, such a thing is obviously trivial. The opposite case for adding stuff for the host to provide for the plugin is similar. Best practice is to return a struct filled with function pointers (so things can be added to it without breakage). In slightly higher level terms, what this allows you to do is add whatever functions you want to any plugin, in a very easy and straightforward manner with no bureaucratic overhead or anything else getting in your way. Not actually documenting things is obviously foolish, but feel free, just like shared libraries. How can this mechanism possibly be to blame for things not being implemented? There's virtually no overhead whatsoever to getting the job done, that's the entire point! Again, this lets you very easily add whatever functions to a plugin you want. There is no voodoo here. I am not obscuring any details, or anything like that. That's really it. You can add whatever you want, extremely easily. Blaming the extension mechanism for such and such not being implemented is every bit as nonsensical as blaming the shared library mechanism for the same. You can easily write whatever functions you want, in either case. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, Oct 31, 2009 at 3:12 PM, David Robillard wrote:
> They are both literally just mechanisms to get a pointer to some
> code/data by name. It's really quite simple... I'm not sure where this
> conception that there's some kind of hard to understand complex
> mechanism involved here comes from, but there really isn't at all.
> "Mechanism" isn't even an appropriate word, really, it's just a
> function. It's as straightforward as straightforward can be. Look at
> the header:
Nobody has suggested that this is hard to understand.
if i am writing a plugin, using LADSPA or VST or AU etc, and the API
does not provide some functionality that I would like to use, i am
stuck. i have to use what is there. end of story.
if i am writing a host that supports those same plugin APIs, and it
doesn't provide some functionality that i would like to use, i am
stuck. i have to use what is there. end of story.
If i am wrting a plugin, and the current LV2 spec + existing
extensions do not provide some functionality that I would like to use,
then i can create a new extension. excellent.
oh, but now i have to get the host(s) to support it. not quite so excellent.
if i am writing a host then ditto ...
nobody (certainly not me) is suggesting that there is anything *hard
to understand* about this. the extension mechanism is well designed,
easy to use and supremely flexible.
but the extension *concept* requires a level of co-evolution between
hosts & plugins that is new and unfamiliar to those who have
previously been involved in both. people who have issues with static
plugin APIs work to find workarounds for limitations for the APIs.
that's arguably stupid and the extension mechanism is a much better
way of tackling the problem.
BUT ... actually using requires interactions betweens host & plugin
authors in new ways, and *that* is what is hard about this, not the
design or how to use it. the new ways have implications for users too,
because every new extension used by a plugin effectively bumps (or
branches) the "version" of LV2 that a plugin is using. its no longer
possible to ask "does a host support LV2?" - a user has to know the
answer to a much more specific question ("LV2 + extA + extB + ... ?").
its easy for software to discover the answer to this, but not so easy
for a user (or even a plugin developer).
this is what i believe jorn meant about "social engineering". you've
designed a new and better way to evolve a plugin API, but for it be
successful requires quite different things from the ecosystem than a
static (and likely inadequate) API. those are things are not easy to
come by.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote:
> On Sat, Oct 31, 2009 at 3:12 PM, David Robillard wrote:
>
> > They are both literally just mechanisms to get a pointer to some
> > code/data by name. It's really quite simple... I'm not sure where this
> > conception that there's some kind of hard to understand complex
> > mechanism involved here comes from, but there really isn't at all.
> > "Mechanism" isn't even an appropriate word, really, it's just a
> > function. It's as straightforward as straightforward can be. Look at
> > the header:
>
> Nobody has suggested that this is hard to understand.
>
> if i am writing a plugin, using LADSPA or VST or AU etc, and the API
> does not provide some functionality that I would like to use, i am
> stuck. i have to use what is there. end of story.
>
> if i am writing a host that supports those same plugin APIs, and it
> doesn't provide some functionality that i would like to use, i am
> stuck. i have to use what is there. end of story.
>
> If i am wrting a plugin, and the current LV2 spec + existing
> extensions do not provide some functionality that I would like to use,
> then i can create a new extension. excellent.
Fine and good. Except that's not what's usually said, and that's not
what was initially said here. LV2 is, apparently, a "catastrophic
failure". When it's not that, it's usually FUD or misinformation about
the extension idea itself. Excuses and whining, not arguments and
solutions. I agree there is a difference, and more of the latter would
be nice.
> oh, but now i have to get the host(s) to support it. not quite so excellent.
This is true, but inherent. You get one, and only one of the following:
- LV2 as it is currently, and the ability to solve this problem (and the
eventual outcome that they all get solved) and increase the power of the
whole thing
- Nothing at all
You are free to use GMPI if the latter option sounds appealing :)
There is nothing magical about API defined in an extension as opposed to
"LV2". If LV2 was a monolithic specification - well, it wouldn't
actually exist in any finished or usable state at all, but let's make
that huge leap and pretend it is - then this same situation would exist.
Feature foo needs to be implemented by a host regardless. The
difference is, with a monolithic specification feature foo not being
implemented by the host means that host doesn't support anything LV2, at
all, whatsoever, end of story. This is clearly inferior.
> but the extension *concept* requires a level of co-evolution between
> hosts & plugins that is new and unfamiliar to those who have
> previously been involved in both. people who have issues with static
> plugin APIs work to find workarounds for limitations for the APIs.
> that's arguably stupid and the extension mechanism is a much better
> way of tackling the problem.
>
> BUT ... actually using requires interactions betweens host & plugin
> authors in new ways, and *that* is what is hard about this, not the
> design or how to use it.
It requires interactions, but I don't really agree it requires anything
new at all, certainly not in this community. Libraries or plugins,
their interfaces, and the programs that implement/use them always
co-evolve. Of course they do, they either co-evolve or do not evolve
whatsoever and die. It's no different than if it was all crammed into
one kitchen sink specification, then everything still needs to co-evolve
in the same way except the barriers to doing so are MUCH greater, to the
point of basically preventing any evolution whatsoever (a textbook
outcome of bad, non-modular design).
Some people get this, but others just point at the whole thing and
whine, and do nothing. The reasons are purely psychological, not
technical - they don't want to help, and blaming others and the
technology is easier. It is a childish attitude bred by people being
accustomed to gigantic soulless corporations telling them what to do, in
my opinion. It has no place here.
> the new ways have implications for users too,
> because every new extension used by a plugin effectively bumps (or
> branches) the "version" of LV2 that a plugin is using. its no longer
> possible to ask "does a host support LV2?" - a user has to know the
> answer to a much more specific question ("LV2 + extA + extB + ... ?").
> its easy for software to discover the answer to this, but not so easy
> for a user (or even a plugin developer).
In the vast majority of cases, an extension not being supported means
the plugin will work fine but that functionality isn't present in the
host. For example, a command line host may not support GUIs, so the GUI
doesn't work. I don't think this is really all that complicated for a
user to understand, or a problem: a program simply doesn't support GUIs.
It's not like a user has to sit down and enumerate and cross reference
these things or something. It has been designed to gracefully degrade
for exactly this reason.
> this is
Re: [LAD] State of Plugin API's
On 11/01/2009 08:11 AM, David Robillard wrote: > On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote: > >> On Sat, Oct 31, 2009 at 3:12 PM, David Robillard wrote: >> >> >>> They are both literally just mechanisms to get a pointer to some >>> code/data by name. It's really quite simple... I'm not sure where this >>> conception that there's some kind of hard to understand complex >>> mechanism involved here comes from, but there really isn't at all. >>> "Mechanism" isn't even an appropriate word, really, it's just a >>> function. It's as straightforward as straightforward can be. Look at >>> the header: >>> >> Nobody has suggested that this is hard to understand. >> >> if i am writing a plugin, using LADSPA or VST or AU etc, and the API >> does not provide some functionality that I would like to use, i am >> stuck. i have to use what is there. end of story. >> >> if i am writing a host that supports those same plugin APIs, and it >> doesn't provide some functionality that i would like to use, i am >> stuck. i have to use what is there. end of story. >> >> If i am wrting a plugin, and the current LV2 spec + existing >> extensions do not provide some functionality that I would like to use, >> then i can create a new extension. excellent. >> > Fine and good. Except that's not what's usually said, and that's not > what was initially said here. LV2 is, apparently, a "catastrophic > failure". When it's not that, it's usually FUD or misinformation about > the extension idea itself. Excuses and whining, not arguments and > solutions. I agree there is a difference, and more of the latter would > be nice. > > To be fair it was in the context of adoption not as an overall sweeping statement about the entire LV2 system which everyone agrees is a very powerful and flexible model for plugin development and IMO deserves greater recognition as best of breed in open source thinking and wider adoption from the worldwide community of plugin developers. >> oh, but now i have to get the host(s) to support it. not quite so excellent. >> > This is true, but inherent. You get one, and only one of the following: > > - LV2 as it is currently, and the ability to solve this problem (and the > eventual outcome that they all get solved) and increase the power of the > whole thing > > - Nothing at all > > You are free to use GMPI if the latter option sounds appealing :) > > There is nothing magical about API defined in an extension as opposed to > "LV2". If LV2 was a monolithic specification - well, it wouldn't > actually exist in any finished or usable state at all, but let's make > that huge leap and pretend it is - then this same situation would exist. > Feature foo needs to be implemented by a host regardless. The > difference is, with a monolithic specification feature foo not being > implemented by the host means that host doesn't support anything LV2, at > all, whatsoever, end of story. This is clearly inferior. > > So, maybe it would be a good use of time to resolve this inadequacy as a priority before moving onto other items? Cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 1 Nov 2009, Patrick Shirkey wrote: > So, maybe it would be a good use of time to resolve this inadequacy as a > priority before moving onto other items? Doesn't VST do it through branding? VST is for effects, VSTi for instruments (softsynths), etc.? Perhaps LV2 could do a similar sort of branding... with the name defined by the extension. E.g LV2-fx LV2-synth Bonus points if some manner of logo integration could be done, too. Standardizing how this is done would make it easier for application developers and users to understand. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
David Robillard wrote: dave, if you'd really read the my post in its entirety and not jumped at the one provocative catchphrase, you might have noticed that we're pretty much on the same side. heck, i've even begun to dig into larsl's lv2 tutorial. to re-iterate what i had thought i had been communicating: lv2 is a *very* *sexy* piece of *software* *engineering*. the problem is, many people are looking for a *standard*. as a standard, lv2 is ages behind ladspa, because you just don't know what your host will support until a canonical set of extensions has emerged and is generally implemented. don't give me that graceful degradation thing - if a plugin author wants an extension, it's generally mission-critical and the plugin will be unusable except in those few carefully crafted examples you gave. let me dig out the tired old analogy: lv2 is xml. you can define what you need, and anything goes. in principle. ladspa is html. it's ugly, kludgy, non-extensible. but if i put something in , then every friggin browser in the world will underline it in blue and make it perform the action the user expects when she clicks on it. that's quite lame from a software architecture standpoint, but it's really cool for users. i'll be the first to admit that my programming skills are more akin to a html "programmer" than anything real. i can write a ladspa plugin in no time. i could also write a simple ladspa-equivalent lv2 plugin in no time, but using all those cool extensions or probably designing my own is beyond me. hence, no win, and no inclination to pick up lv2. world domination implies you gotta win at least a percentage of the dumb fucks like me, not just the hotshots. please, dig this: i'm talking about the standards aspect, not the engineering aspect. i don't know shit about software engineering, and never claimed otherwise. however, i do know which things pick up momentum and which linger half-dead in the water. actually, the largest part of my post was about strategies to help lv2 pick up momentum. don't give me that M$ FUD shit, either. heck, i've been doing more linux audio advocacy in my life than is good for me, and i really don't see why you're perceiving a little provocative discourse as some sort of intrigue from evil incarnate. just relax. that said, i hope you know i appreciate and respect the work that went into lv2. hence, respectfully yours, jörn ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/01/2009 10:19 AM, Gabriel M. Beddingfield wrote: > > > On Sun, 1 Nov 2009, Patrick Shirkey wrote: > >> So, maybe it would be a good use of time to resolve this inadequacy as a >> priority before moving onto other items? > > Doesn't VST do it through branding? VST is for effects, VSTi for > instruments (softsynths), etc.? > > Perhaps LV2 could do a similar sort of branding... with the name > defined by the extension. > > E.g > > LV2-fx > LV2-synth > > Bonus points if some manner of logo integration could be done, too. > > Standardizing how this is done would make it easier for application > developers and users to understand. > In addition, presenting the extensions and the plugins that have been built with them on the website in a way that encourages developers to integrate them would be helpful for adoption. It has been said before that there is a problem with documentation for LV2. Perhaps the system needs to be more automated. I'm not sure what the limitations of the existing system are but in general having a central location where all extensions are collated with explicit details about their usage and examples for how to write code for them them would go a long way to making the system more developer friendly. Providing a weekly/monthly mailout which lists the new extensions and a brief description with links to code examples and usage cases would also be helpful for developers who want to keep up to date with the latest offerings. Essentially spending some time on automating the notifications system now will be useful for everyone and could go a long way to increase the pickup and development rate for LV2 which is good for everyone. It just so happens that I have some free time I can put aside for this over the next 6 weeks. If we can agree on what is missing from the existing system I will spend some time on integrating it. I could put aside 4 hours on Wed nights for this project. So, can those in the know please spend some time to think about the things that are currently missing from the LV2 ecosystem and I will get onto it. @Dave, I assume you have a feature/task list that you are working with so if you want to hand any specific house keeping tasks to me then fire away. Cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
wrote:
[ ... stuff ]
the idea occured to me sometime today.
"my host supports LV2-E1"
"my plugin requires LV2-E2"
"this application uses LV2-E"
EV = LV2 core + { extA, extB, extC .. }
its not a new idea, i'm just "naming" it.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/01/2009 02:38 PM, Paul Davis wrote:
> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
> wrote:
>
> [ ... stuff ]
>
> the idea occured to me sometime today.
>
> "my host supports LV2-E1"
> "my plugin requires LV2-E2"
> "this application uses LV2-E"
>
> EV = LV2 core + { extA, extB, extC .. }
>
> its not a new idea, i'm just "naming" it.
>
That seems fairly logical.
Not specifically to you but I wonder how would we assign extension
numbers to that the EV is a unique number?
Cheers.
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
2009/11/1 Patrick Shirkey :
>
> On 11/01/2009 02:38 PM, Paul Davis wrote:
>> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
>> wrote:
>>
>> [ ... stuff ]
>>
>> the idea occured to me sometime today.
>>
>> "my host supports LV2-E1"
>> "my plugin requires LV2-E2"
>> "this application uses LV2-E"
>>
>> EV = LV2 core + { extA, extB, extC .. }
>>
>> its not a new idea, i'm just "naming" it.
>>
>
>
> That seems fairly logical.
>
> Not specifically to you but I wonder how would we assign extension
> numbers to that the EV is a unique number?
To me this is nonsense, the best way to do that I can imagine is
assigning one bit position to each extension and sum them up to give
your , but I can already imagine huge unreadable numbers (how many
extensions do we have now? 20?) and probably there's no better way to
do that.
This also clashes IMO with the idea of using URIs for decentralized
extension development (no, please, not unique ids again!)
Anyway, this sounds as a really marginal thing to me... but maybe it's not?
Regards,
Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, Nov 1, 2009 at 4:59 AM, Stefano D'Angelo wrote: > To me this is nonsense, the best way to do that I can imagine is > assigning one bit position to each extension and sum them up to give > your , but I can already imagine huge unreadable numbers (how many > extensions do we have now? 20?) and probably there's no better way to > do that. the idea is not to enumerate *all* extensions. it is to define a name for a particular rev of LV2 core plus a particular set of extensions. if there were 10,000 extensions but the generally accepted practice was to support 10 of them, what use would there be in somehow indicating support for any/all of the 10k via some kind of number or name? > This also clashes IMO with the idea of using URIs for decentralized > extension development (no, please, not unique ids again!) it clashes with it to the same extent as having "LV2 core rev 3" does. the "LV2-E" designation isn't intended to define an extension, its intended to define a version of LV2, or, if you like, a standard for LV2, not just LV2 core. one example that springs to mind here is MMC. it didn't have decentralized development, but my understanding is that the process of specifying it effectively collected new commands and new state from just about every participant. rather than require that any implementation of MMC supported them all, or supported some random subset of them, they defined four "levels" of support. MMC Level 1 is a common core set of commands and state that any MMC device must support. Level 2 makes the spec a bit more useful. Levels 3 and 4 are really not that important unless you have a very specific type of device. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
2009/11/1 Paul Davis : > On Sun, Nov 1, 2009 at 4:59 AM, Stefano D'Angelo wrote: > >> To me this is nonsense, the best way to do that I can imagine is >> assigning one bit position to each extension and sum them up to give >> your , but I can already imagine huge unreadable numbers (how many >> extensions do we have now? 20?) and probably there's no better way to >> do that. > > the idea is not to enumerate *all* extensions. it is to define a name > for a particular rev of LV2 core plus a particular set of extensions. > if there were 10,000 extensions but the generally accepted practice > was to support 10 of them, what use would there be in somehow > indicating support for any/all of the 10k via some kind of number or > name? > >> This also clashes IMO with the idea of using URIs for decentralized >> extension development (no, please, not unique ids again!) > > it clashes with it to the same extent as having "LV2 core rev 3" does. > the "LV2-E" designation isn't intended to define an extension, its > intended to define a version of LV2, or, if you like, a standard for > LV2, not just LV2 core. > > one example that springs to mind here is MMC. it didn't have > decentralized development, but my understanding is that the process of > specifying it effectively collected new commands and new state from > just about every participant. rather than require that any > implementation of MMC supported them all, or supported some random > subset of them, they defined four "levels" of support. MMC Level 1 is > a common core set of commands and state that any MMC device must > support. Level 2 makes the spec a bit more useful. Levels 3 and 4 are > really not that important unless you have a very specific type of > device. Sorry, I didn't really get what you were meaning then. In this case it's surely possible, but would it really be much more "readable" to use a number than to state the name of such extensions or, even better, define sets of extensions as "levels"? I mean, 10 extensions means numbers from 0 to 1023, and you have to know binary arithmetics to make sense of which extensions are supported... not very marketing friendly. Better to define "level 1", "level 2", etc. IMO. Anyway, since this does not affect LV2 as a specification, I just really don't care. The one thing I would care about is how/which extensions would belong to a certain standard/set, etc. Best regards, Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, Nov 1, 2009 at 7:53 AM, Stefano D'Angelo wrote:
> Sorry, I didn't really get what you were meaning then.
>
> In this case it's surely possible, but would it really be much more
> "readable" to use a number than to state the name of such extensions
> or, even better, define sets of extensions as "levels"?
>
> I mean, 10 extensions means numbers from 0 to 1023, and you have to
> know binary arithmetics to make sense of which extensions are
> supported... not very marketing friendly. Better to define "level 1",
> "level 2", etc. IMO.
i meant to use a name. LV2-E would simply mean LV2 core + {some
defined set of extensions}. plugin and host authors could then talk
about using "LV2-E".
the E part merely designates a particular set of extensions, which
might be 2 extensions, or 100.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 1 Nov 2009, Paul Davis wrote:
>
> i meant to use a name. LV2-E would simply mean LV2 core + {some
> defined set of extensions}. plugin and host authors could then talk
> about using "LV2-E".
> the E part merely designates a particular set of extensions, which
> might be 2 extensions, or 100.
So... something like this?
LV2-EBasic := LV2 core + URI Map + MIDI Event
LV2-EPlus := LV2-EBasic + External UI
LV2-EExtreme := LV2-EPlus + dynparam + Progress
LV2-EVideo := LV2-EBasic + SMTP + Transport
Note: Yes, I know some of those extensions don't exist or are proposals.
Some may not even relate. I'm still trying to understand it. :-)
BTW: Some of the extension API's seem more like plumbing. Resources for
communicating between plugins. Things that have little relevence to the
end user. For example, the URI Map seems like it's just a utility for an
extension or a plugin -- but the host doesn't necc. need to add support
for it. Is this right?
Peace,
Gabriel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 09:44 +1100, Patrick Shirkey wrote: > On 11/01/2009 08:11 AM, David Robillard wrote: > > On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote: > > > >> On Sat, Oct 31, 2009 at 3:12 PM, David Robillard wrote: [...] > >> If i am wrting a plugin, and the current LV2 spec + existing > >> extensions do not provide some functionality that I would like to use, > >> then i can create a new extension. excellent. > >> > > Fine and good. Except that's not what's usually said, and that's not > > what was initially said here. LV2 is, apparently, a "catastrophic > > failure". When it's not that, it's usually FUD or misinformation about > > the extension idea itself. Excuses and whining, not arguments and > > solutions. I agree there is a difference, and more of the latter would > > be nice. > > > > > > To be fair it was in the context of adoption not as an overall sweeping > statement about the entire LV2 system which everyone agrees is a very > powerful and flexible model for plugin development and IMO deserves > greater recognition as best of breed in open source thinking and wider > adoption from the worldwide community of plugin developers. Fair enough :) > > There is nothing magical about API defined in an extension as opposed to > > "LV2". If LV2 was a monolithic specification - well, it wouldn't > > actually exist in any finished or usable state at all, but let's make > > that huge leap and pretend it is - then this same situation would exist. > > Feature foo needs to be implemented by a host regardless. The > > difference is, with a monolithic specification feature foo not being > > implemented by the host means that host doesn't support anything LV2, at > > all, whatsoever, end of story. This is clearly inferior. > So, maybe it would be a good use of time to resolve this inadequacy as a > priority before moving onto other items? ? The inadequacy is with a hypothetical monolithic alternative to LV2, not with LV2. If LV2 attempted to go this way, there would be /zero/ adoption... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 01:11 +0100, Jörn Nettingsmeier wrote: > David Robillard wrote: > > > > dave, if you'd really read the my post in its entirety and not jumped at > the one provocative catchphrase, you might have noticed that we're > pretty much on the same side. heck, i've even begun to dig into larsl's > lv2 tutorial. > > to re-iterate what i had thought i had been communicating: > > lv2 is a *very* *sexy* piece of *software* *engineering*. > > the problem is, many people are looking for a *standard*. > > as a standard, lv2 is ages behind ladspa, because you just don't know > what your host will support until a canonical set of extensions has > emerged and is generally implemented. don't give me that graceful > degradation thing - if a plugin author wants an extension, it's > generally mission-critical and the plugin will be unusable except in > those few carefully crafted examples you gave. "Core" LV2 is more powerful than LADSPA. In addition, there's other features you can use. Saying this is ages behind LADSPA makes no sense whatsoever. I don't think your "mission critical" statement is true at all. GUIs, presets, most port types, can all easily gracefully degrade. Calling these "well-crafted" examples is a bit of a stretch. Where are your well crafted examples? ;) > let me dig out the tired old analogy: lv2 is xml. you can define what > you need, and anything goes. in principle. > ladspa is html. it's ugly, kludgy, non-extensible. but if i put > something in , then every friggin browser in the world will > underline it in blue and make it perform the action the user expects > when she clicks on it. that's quite lame from a software architecture > standpoint, but it's really cool for users. A is fundamental. Embedded SVG is not. X(HT)ML supports embedded SVG. If your browser doesn't support it, that part simply doesn't work. You are arguing that any browser that does not support embedded SVG /should not work at all/. Does that make sense to developers? No. Does it make sense to users? No. Is that how the web works? No. Why? Because it's stupid and has no advantage whatsoever. > i'll be the first to admit that my programming skills are more akin to a > html "programmer" than anything real. i can write a ladspa plugin in no > time. i could also write a simple ladspa-equivalent lv2 plugin in no > time, but using all those cool extensions or probably designing my own > is beyond me. hence, no win, and no inclination to pick up lv2. > world domination implies you gotta win at least a percentage of the dumb > fucks like me, not just the hotshots. Using them can't be beyond you if writing a basic plugin isn't. Writing one may be. So what? Wait until the hotshots finish those extensions, then. You are just whining that such and such a feature hasn't been done yet. The mechanism, for the 9 billionth time, has nothing to do with this. You are assuming that the whole thing is just so dreadfully complex to use in order to make this argument, which is not true. > please, dig this: i'm talking about the standards aspect, not the > engineering aspect. i don't know shit about software engineering, and > never claimed otherwise. however, i do know which things pick up > momentum and which linger half-dead in the water. > actually, the largest part of my post was about strategies to help lv2 > pick up momentum. You can give a silly name to LV2 + some "standard" package of extensions if you please. You can invent 18 different baroque little "categories" of extensions for no reason whatsoever if you like. It is a more or less completely pointless thing to do, but if you like marketing, feel free. You can design pretty little logos and everything, whee. It doesn't change anything. > don't give me that M$ FUD shit, either. heck, i've been doing more linux > audio advocacy in my life than is good for me, and i really don't see > why you're perceiving a little provocative discourse as some sort of > intrigue from evil incarnate. just relax. > > that said, i hope you know i appreciate and respect the work that went > into lv2. hence, No personal ill-will. I'm plenty relaxed, but somebody has to set the record straight of the constant stream of misleading LV2 slander you're pumping out. If it's not obvious, this kind of thing irks me because your arguments are completely false and ridiculous, dripping with fallacy and hand waving and all the other infuriating things about people being stupid on the internet. That /is/ evil incarnate ;) My point with the FUD thing was that, even though I'm sure you and (some) others aren't malicious, saying things like this does harm LV2. I have seen it happen, developers write the whole thing off because they read things like your criticism and figure the whole thing is a hopeless mess. It is not a hopeless mess, the sky is not falling, and all this "standards" crap is just hand-waving. The things you are saying are false and misleading. Not
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 12:09 +1100, Patrick Shirkey wrote: > On 11/01/2009 10:19 AM, Gabriel M. Beddingfield wrote: > > > > > > On Sun, 1 Nov 2009, Patrick Shirkey wrote: > > > >> So, maybe it would be a good use of time to resolve this inadequacy as a > >> priority before moving onto other items? > > > > Doesn't VST do it through branding? VST is for effects, VSTi for > > instruments (softsynths), etc.? > > > > Perhaps LV2 could do a similar sort of branding... with the name > > defined by the extension. > > > > E.g > > > > LV2-fx > > LV2-synth > > > > Bonus points if some manner of logo integration could be done, too. > > > > Standardizing how this is done would make it easier for application > > developers and users to understand. > > > > > In addition, presenting the extensions and the plugins that have been > built with them on the website in a way that encourages developers to > integrate them would be helpful for adoption. > > It has been said before that there is a problem with documentation for > LV2. Perhaps the system needs to be more automated. This is definitely true, the site and documentation needs work. Making things like "LV2-fx", whatever the would be though, is pointless. There would be too many of them, what gets in and what doesn't would be just a big silly debate with no point. Most features apply equally to both anyway. "Features" are not difficult for users to understand! VSTi vs VST is basically just a product of VST being crap :) The only difference between a "synth" and an "fx" plugin in LV2 is one happens to have a MIDI port, and probably a certain plugin category under "Instruments", etc. It really doesn't mean much at all. > I'm not sure what the limitations of the existing system are but in > general having a central location where all extensions are collated with > explicit details about their usage and examples for how to write code > for them them would go a long way to making the system more developer > friendly. > > Providing a weekly/monthly mailout which lists the new extensions and a > brief description with links to code examples and usage cases would also > be helpful for developers who want to keep up to date with the latest > offerings. > > Essentially spending some time on automating the notifications system > now will be useful for everyone and could go a long way to increase the > pickup and development rate for LV2 which is good for everyone. > The volume isn't really big enough for this, to be honest. We can set up an RSS feed or something, or an announce list, but I really don't see this as being an effective thing to worry about at this point in time. You'd be automating nothing. Need an actual nice presentation for extensions first, before announcing matters. The mailing list is low volume enough that any developers interested in LV2 goins-on should simply be on that. I'll look into adding RSS to my documentation generator thingie though, that's kind of a cool idea. > It just so happens that I have some free time I can put aside for this > over the next 6 weeks. If we can agree on what is missing from the > existing system I will spend some time on integrating it. I could put > aside 4 hours on Wed nights for this project. > > So, can those in the know please spend some time to think about the > things that are currently missing from the LV2 ecosystem and I will get > onto it. > > @Dave, I assume you have a feature/task list that you are working with > so if you want to hand any specific house keeping tasks to me then fire > away. Awesome, thanks. I think the main problem right now is that the site is stagnant. I think maybe the most feasible path, effort wise, would be just to move all the content over to the Wiki, which is easy for everyone to participate with, and nuke the site. I could probably get Steve to install Drupal or Wordpress and make a bit more of a "professional" looking site that way, but it's more work, and then we have two account systems instead of one. Is there any advantage to this beyond pretty? Seems no, and adding content is a bit more tedious. So maybe the best housekeepingey thing to do right now is get all the content over to the wiki, and tidy up the wiki, then we can make it the main page for http://lv2plug.in ? Cheers, -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sat, 2009-10-31 at 23:38 -0400, Paul Davis wrote:
> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
> wrote:
>
>[ ... stuff ]
>
> the idea occured to me sometime today.
>
> "my host supports LV2-E1"
> "my plugin requires LV2-E2"
> "this application uses LV2-E"
>
> EV = LV2 core + { extA, extB, extC .. }
Trying to put the entire "extension ecosystem" on a linear scale is
definitely completely impossible.
-dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 06:07 -0500, Paul Davis wrote: > one example that springs to mind here is MMC. it didn't have > decentralized development, but my understanding is that the process of > specifying it effectively collected new commands and new state from > just about every participant. rather than require that any > implementation of MMC supported them all, or supported some random > subset of them, they defined four "levels" of support. MMC Level 1 is > a common core set of commands and state that any MMC device must > support. Level 2 makes the spec a bit more useful. Levels 3 and 4 are > really not that important unless you have a very specific type of > device. But nobody needed to define MIDI+MMC and MIDI+MTC and MIDI+MMC1 and MIDI +MMC2 and MIDI+MMC1+MTC and MIDI+MMC2+MTC and ... for people to make sense of the whole thing, did they? :) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 08:34 -0600, Gabriel M. Beddingfield wrote:
>
> On Sun, 1 Nov 2009, Paul Davis wrote:
> >
> > i meant to use a name. LV2-E would simply mean LV2 core + {some
> > defined set of extensions}. plugin and host authors could then talk
> > about using "LV2-E".
> > the E part merely designates a particular set of extensions, which
> > might be 2 extensions, or 100.
>
> So... something like this?
>
> LV2-EBasic := LV2 core + URI Map + MIDI Event
>
> LV2-EPlus := LV2-EBasic + External UI
>
> LV2-EExtreme := LV2-EPlus + dynparam + Progress
>
> LV2-EVideo := LV2-EBasic + SMTP + Transport
Don't forget LV2-Premium-Turbo-2000-Professional-Edition
> BTW: Some of the extension API's seem more like plumbing. Resources for
> communicating between plugins. Things that have little relevence to the
> end user. For example, the URI Map seems like it's just a utility for an
> extension or a plugin -- but the host doesn't necc. need to add support
> for it. Is this right?
The host must support it (if host and plugin don't need to agree on it,
doesn't really make sense to be an extension anyway). The extension
defines a way for hosts to provide a URI<->int mapping facility to
plugins. It's generically very useful, and I would suspect that
many/most future extensions will depend on it.
-dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, Nov 1, 2009 at 12:14 PM, David Robillard wrote:
> On Sat, 2009-10-31 at 23:38 -0400, Paul Davis wrote:
>> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
>> wrote:
>>
>> [ ... stuff ]
>>
>> the idea occured to me sometime today.
>>
>> "my host supports LV2-E1"
>> "my plugin requires LV2-E2"
>> "this application uses LV2-E"
>>
>> EV = LV2 core + { extA, extB, extC .. }
>
> Trying to put the entire "extension ecosystem" on a linear scale is
> definitely completely impossible.
specifically *not* the entire extension ecosystem.
subsets of the ecosystem that can be named, referenced, referred to,
*developed against* by plugin/host authors, with some expectations.
when you give examples from the web, i think there is an interesting
lesson there. people with an interest in extending "html" in some way
(e.g. embedded svg, theora, whatever) know what the path is: develop
the technology/specs/etc, get some initial implementations, push
toward w3c ... adoption by w3c (if you're lucky).
a similar path exists for LV2 except for the last part. you can argue
that its the cart before the horse - develop the stuff first, then
lets argue about how its to be part of a named "ensemble" or
"standard" or whatever. but i would contend that part of the reason
for a reluctance to develop (which you pointedly referenced) is the
lack of any clue what happens *after* that. you know, its great that
LV2 lets anyone and their mom define a cool new way to do ramped
plugin parameter control. but so what? how is that of any interest to
someone who wants to figure out, not just a technical solution to the
issue, but an accepted, in-use engineering solution? if the pathway to
the second part isn't clear, the first part is less likely to get
done.
with LADSPA, it was very easy to motivate discussions about design
changes - there was one header, and it got into the header, or it
didn't. its similarly easy, when necessary, to do the same for JACK -
once again, there is one header, one API and something is either in
or out, or modified. LV2's glorious anarchy means that there is no
social necessity for any convergent effort at all. people can do
whatever the hell they want (good!) and nobody else need care (bad!).
ok, so people don't agree yet on how to do plugin API feature X ...
then we need a mechanism that does more to force us to actually come
up with solutions. LV2 doesn't do anything to force this, possibly by
design. its no suprise, therefore, that people who might feel a
pressing need for this or that don't do anything about it, because its
not actually clear to them that it will be a "solution" at all.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 10:10 -0400, Paul Davis wrote:
> On Sun, Nov 1, 2009 at 7:53 AM, Stefano D'Angelo wrote:
>
> > Sorry, I didn't really get what you were meaning then.
> >
> > In this case it's surely possible, but would it really be much more
> > "readable" to use a number than to state the name of such extensions
> > or, even better, define sets of extensions as "levels"?
> >
> > I mean, 10 extensions means numbers from 0 to 1023, and you have to
> > know binary arithmetics to make sense of which extensions are
> > supported... not very marketing friendly. Better to define "level 1",
> > "level 2", etc. IMO.
>
> i meant to use a name. LV2-E would simply mean LV2 core + {some
> defined set of extensions}. plugin and host authors could then talk
> about using "LV2-E".
> the E part merely designates a particular set of extensions, which
> might be 2 extensions, or 100.
What problem does this solve? The functionality itself is defined in
terms of specific features. Host and plugin authors can talk about
support for "the transport extension", or whatever, as they do now.
Is there any real point to this other than blind VST emulation? I don't
think it has ever once come up that someone needs to talk about some
specific large set of extensions as a whole and it's tedious to
enumerate them all, or whatever.
This kind of effort is mostly a time sink for people who are powerfully
inclined to making baroque categorizations for everything. It seems to
be an almost religious fervor with some people (who should never be let
within 100 feet of a design document), I find the whole thing really
kind of amazing.
Anyway! More concretely, the reasons this is silly are obvious if you
think about it. There is simply no such categorization. Blahrdour
likes "effects" and "synths", can support "presets", has a concept of
"transport". Blingen likes "effects" and "synths" as well, can support
"presets", has no concept of "transport". Which category does
"transport" go into, then? It's not really related to any of the other
things at all, it's a completely independent feature. This is true of
most extensions.
Even if one came up with such a baroque categorization, it would be
worthess, because the number of exceptions would pretty much the same as
the number of supported things anyway. Pretending that everything would
fit into these nice little boxes to support the effort is silly - they
won't.
Now, that said, there is ONE such "standard" that I do support - namely
extensions that have been peer-reviewed (on the lv2 dev mailing list),
accepted by consensus, and implemented by at least 2 plugins and hosts
(this is already the consensus on what gets to have a http://lv2plug.in
URI). This is definitely a good idea, and if someone wants to come up
with a fancy name for it, feel free. Multiple categorizations is a
fool's errand, but making clear what the community has taken a good look
at and accepted, and what's just some random kludgey thing patching a
hole for somebody in the short term, is definitely a high priority goal.
-dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
David Robillard wrote: > On Sun, 2009-11-01 at 01:11 +0100, Jörn Nettingsmeier wrote: >> as a standard, lv2 is ages behind ladspa, > "Core" LV2 is more powerful than LADSPA. In addition, there's other > features you can use. Saying this is ages behind LADSPA makes no sense > whatsoever. dave, "powerful" is about engineering quality. a standard (even if it is shoddily engineered) is good if i can adhere to it and be sure my stuff will work somewhere else. these issues are *orthogonal*. don't pee your pants, i'm not criticising the engineering part. what makes a standard successful is *market* *penetration* - everybody and their grandma implements ladspa because it's simple. implementing lv2 is harder. there are good reasons for it - it's better in every respect, except in uptake. there is an entrance barrier to it. you can ignore it and piss off people who point it out, but that's not going to remove it. > I don't think your "mission critical" statement is true at all. GUIs, > presets, most port types, can all easily gracefully degrade. Calling > these "well-crafted" examples is a bit of a stretch. Where are your > well crafted examples? ;) ardour and other hosts frequently exploding in the presence of yet-unbeknownst lv2 features? yeah, in theory, they shouldn't do that :) or try to make sense of the swh gate plugin in the absence of epp:logarithmic... > The mechanism, for the 9 billionth time, has nothing to do > with this. You are assuming that the whole thing is just so dreadfully > complex to use in order to make this argument, which is not true. i'm not talking about mechanism. the mechanism is fine. i'm talking about the politics of getting a usable standard out there. the increased power of lv2 comes at the cost of greater complexity, which in return slows down the adoption. >> don't give me that M$ FUD shit, either. heck, i've been doing more linux >> audio advocacy in my life than is good for me, and i really don't see >> why you're perceiving a little provocative discourse as some sort of >> intrigue from evil incarnate. just relax. >> >> that said, i hope you know i appreciate and respect the work that went >> into lv2. hence, > > No personal ill-will. I'm plenty relaxed, but somebody has to set the > record straight of the constant stream of misleading LV2 slander you're > pumping out. > If it's not obvious, this kind of thing irks me because > your arguments are completely false and ridiculous, dripping with > fallacy and hand waving and all the other infuriating things about > people being stupid on the internet. That /is/ evil incarnate ;) your definition of "plenty relaxed" seems to differ from mine quite substantially :-D the "standard" aspect of lv2 is not done yet. which is plainly evident from the fact that most innovative lv2 plugins that show up require patches to the host in order to work - it's not clear to host writers what they should implement, and plugin writers can't assume what will work in any given host. until that changes, lv2 is not a successful standard. and it takes other skills that software engineering to change that, which you seem to be a) unwilling to acknowledge and b) lacking. hence, i'd better give up now. how a person with arguably twice my iq can so painstakingly kepp missing the point i was trying to make is mystifying. but it seems pretty pointless to rehash it all over. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 1 Nov 2009, David Robillard wrote: > But nobody needed to define MIDI+MMC and MIDI+MTC and MIDI+MMC1 and MIDI > +MMC2 and MIDI+MMC1+MTC and MIDI+MMC2+MTC and ... for people to make > sense of the whole thing, did they? :) Yes and No. Manufacturers are required to publish their MIDI Implementation so that the person buying the device would know what types of MIDI messages the device sends and responds to. This includes the summarized table and the down-to-each-sysex-bit documentation. If you know you want an MMC-capable device, you know to look here. If you don't want to do LV2-EXtremeMakeover-HomeEdition or LV2-El33t, then perhaps a concise table with a standardized format might work better for you. Or even a just a standardized way of saying it. Something more clear and concise than "Foomatic-LV2 depends on the URI Map extension and the MIDI Ports extension [exactly /who/ is supposed to supply these?]. And, oh yeah, we forgot to tell you about the dynparam extension... but I'm sure you'll figure that out when things don't work." -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 12:24 -0400, Paul Davis wrote:
> On Sun, Nov 1, 2009 at 12:14 PM, David Robillard wrote:
> > On Sat, 2009-10-31 at 23:38 -0400, Paul Davis wrote:
> >> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
> >> wrote:
> >>
> >>[ ... stuff ]
> >>
> >> the idea occured to me sometime today.
> >>
> >> "my host supports LV2-E1"
> >> "my plugin requires LV2-E2"
> >> "this application uses LV2-E"
> >>
> >> EV = LV2 core + { extA, extB, extC .. }
> >
> > Trying to put the entire "extension ecosystem" on a linear scale is
> > definitely completely impossible.
>
> specifically *not* the entire extension ecosystem.
>
> subsets of the ecosystem that can be named, referenced, referred to,
> *developed against* by plugin/host authors, with some expectations.
>
> when you give examples from the web, i think there is an interesting
> lesson there. people with an interest in extending "html" in some way
> (e.g. embedded svg, theora, whatever) know what the path is: develop
> the technology/specs/etc, get some initial implementations, push
> toward w3c ... adoption by w3c (if you're lucky).
> a similar path exists for LV2 except for the last part. you can argue
> that its the cart before the horse - develop the stuff first, then
> lets argue about how its to be part of a named "ensemble" or
> "standard" or whatever. but i would contend that part of the reason
> for a reluctance to develop (which you pointedly referenced) is the
> lack of any clue what happens *after* that. you know, its great that
> LV2 lets anyone and their mom define a cool new way to do ramped
> plugin parameter control. but so what? how is that of any interest to
> someone who wants to figure out, not just a technical solution to the
> issue, but an accepted, in-use engineering solution? if the pathway to
> the second part isn't clear, the first part is less likely to get
> done.
Meh, I don't think that's true at all. All of this stuff is not a
barrier to anyone actually doing the work at all. Honestly, be
realistic. What kind of developer on a mission to get ramped control
ports sits down to solve the problem and goes OH GOD THERE'S NO W3C
STANDARDS BODY TO SUBMIT TO THAT WILL FOLD THIS EXTENSION INTO SOME KIND
OF META STANDARD WITH A FANCY NAME THEREFORE MY EFFORTS ARE WASTED!
Please ;)
These developers DO come along and they DO do things. Stefano, who is
also participating in this discussion, is a good example. He showed up
a little while ago on a mission to get dynamic plugin discovery working,
things were discussed on the list as necessary, and things got done.
Reality. Notice the common theme around here of people who havn't
actually looked into doing anything at all like to scream endlessley
about these supposed problems, but everyone who actually /has/ either
doesn't participate at all, or actively disagrees? It's not a
coincidence, because these problems are completely fictitious.
> with LADSPA, it was very easy to motivate discussions about design
> changes
And even easier for them to go nowhere at all...
> - there was one header, and it got into the header, or it
> didn't.
Which in reality, after the initial one is out, means it didn't, ever.
Use LADSPA if you think that plan is so fantastic. It's no coincidence
that it's a complete and utter joke power-wise compared to all of its
competition.
> its similarly easy, when necessary, to do the same for JACK -
> once again, there is one header, one API and something is either in
> or out, or modified. LV2's glorious anarchy means that there is no
> social necessity for any convergent effort at all.
Of course there is, multiple extensions for the same thing really sucks
for everybody involved. That is the social necessity. If you think
some kind of fascist design dictatorship of LV2 solves this better than
evolution, I direct you to Linus' recently famous comments on lkml about
this one ;)
You say it's easier to modify Jack and LADSPA than LV2. This is so
wrong it hurts. How do you add functionality to LADSPA? You fight
endlessly on this list and nothing gets done. It's happened countless
times before. How do you do it for LV2? YOU JUST DO IT! It is
provably easier, because the actual task is the same, except there is no
bureaucratic overhead.
If you really wish to argue this point, then I will present a simple
challenge: design and implement ramped control ports for LADSPA, and I
will do so for LV2. The winner is whoever gets it working and
implemented without breaking any standard - that is, gets it working in
the real world. You would obviously be insane to accept this challenge,
because actually improving LADSPA is so insanely hard it's basically
impossible, and there is no barrier whatsoever to actually improving
LV2. I'd be done by the time you even get a reply to your first email
about it in the ensuing never-ending discussion that goes nowhere. Your
assumption is so false as to be almost completely backwards. LV2 is,
litera
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 17:39 +0100, Jörn Nettingsmeier wrote: > David Robillard wrote: > > On Sun, 2009-11-01 at 01:11 +0100, Jörn Nettingsmeier wrote: > >> as a standard, lv2 is ages behind ladspa, > > > "Core" LV2 is more powerful than LADSPA. In addition, there's other > > features you can use. Saying this is ages behind LADSPA makes no sense > > whatsoever. > > dave, "powerful" is about engineering quality. a standard (even if it is > shoddily engineered) is good if i can adhere to it and be sure my stuff > will work somewhere else. > > these issues are *orthogonal*. don't pee your pants, i'm not criticising > the engineering part. > > what makes a standard successful is *market* *penetration* - everybody > and their grandma implements ladspa because it's simple. implementing > lv2 is harder. there are good reasons for it - it's better in every > respect, except in uptake. there is an entrance barrier to it. you can > ignore it and piss off people who point it out, but that's not going to > remove it. Implementing LV2 via SLV2 is quite a bit easier than implementing LADSPA directly. That's why I wrote it. ;) You suggest /I/ relax, which is slightly entertaining. You're the one running around like a chicken with its head cut off pointing out all these supposedly catastrophic problems. What problems? I don't see any problems. I see some things that need doing. I, and others, will get around to doing them as we see fit, as always. There are no barriers to doing so, thus there is no problem. The only problem is your lack of patience. > i'm not talking about mechanism. the mechanism is fine. i'm talking > about the politics of getting a usable standard out there. Politics do not write code. Period. > the "standard" aspect of lv2 is not done yet. which is plainly evident > from the fact that most innovative lv2 plugins that show up require > patches to the host in order to work So you get to redefine "standard" as you please to make your point. Convenient. LV2 is not a "standard" until it includes a coffee maker and a golf course as well, I suppose? > and it takes other skills that software engineering to change that, > which you seem to be a) unwilling to acknowledge and b) lacking. I'm lacking? How many extensions have you authored, mouthpiece? > hence, i'd better give up now. how a person with arguably twice my iq > can so painstakingly kepp missing the point i was trying to make is > mystifying. but it seems pretty pointless to rehash it all over. I pointed out quite clearly why your points are faulty. Why anyone, regardless of IQ, can fail to understand is, is beyond me. It is indeed pointless to state nonsense over and over and over, it doesn't make it any more correct. Sometimes it's useful to continually repeat sense though, as I seemingly have to do. Let's try that: Problem: some features have yet to be implemented. Solution: implement them. That's it. Simple eh? Surely nobody disagrees on the former, that's what this thread is about. Let's try that again, maybe it'll sink in: Problem: some features have yet to be implemented. Solution: implement them. See it? Okay, one more! Problem: some features have yet to be implemented. Solution: implement them. Go back up to the top and read it a few more times. Notice how all the "social" crap you are talking about does not actually solve the problem? Let me play psychologist and make a stab at why: you, like everyone, sees that there are some nice features that aren't implemented yet. However, like everyone who uses the arguments you have been, you have no actual desire to solve the problem yourself. Therefore, you resort to fabricating "social" problems as a reason for them not being implemented, because this justifies your own avoidance of actually solving the problems. Well, sorry, but I have implemented extensions, as have many others, and can tell you from experience that there are no such barriers. They are fabrications designed to make you feel better. Why do I, and others who have actually done some work around this area, not see these barriers? Because they obviously do not exist. If you don't want to help, fine, but don't invent bullshit excuses and claim there's some massive social problem that prevents you from doing so. You and anyone else are more than free to sit down right now and design and implement whatever you please. So what, exactly, is this big social problem? There isn't one. The only "problem" is that you are not satisfied with how quickly other volunteer developers are getting things done. What makes anyone think they have this right is beyond me. If you want an extension so badly but lack the expertise to do so, slide your friendly local neighbourhood LV2 nerd some cash and have them do it for you. Then you can complain all you like, because you have paid for the right to do so. Otherwise, I don't suspect you'd like others complaining that what you do in your free time isn't
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 11:51 -0600, Gabriel M. Beddingfield wrote: > > On Sun, 1 Nov 2009, David Robillard wrote: > > > But nobody needed to define MIDI+MMC and MIDI+MTC and MIDI+MMC1 and MIDI > > +MMC2 and MIDI+MMC1+MTC and MIDI+MMC2+MTC and ... for people to make > > sense of the whole thing, did they? :) > > Yes and No. Manufacturers are required to publish their MIDI > Implementation so that the person buying the device would know what types > of MIDI messages the device sends and responds to. This includes the > summarized table and the down-to-each-sysex-bit documentation. If you > know you want an MMC-capable device, you know to look here. > > If you don't want to do LV2-EXtremeMakeover-HomeEdition or LV2-El33t, then > perhaps a concise table with a standardized format might work better for > you. I agree hosts and plugins should provide this information in an easy to find place, though doing things properly at runtime makes it less necessary than you might think. > And, oh > yeah, we forgot to tell you about the dynparam extension... but I'm sure > you'll figure that out when things don't work." The host has all the information needed to report this explicitly to the user (you can't use plugin foo because this program doesn't support feature bar). Its not like it's just going to mysteriously not work, that's just bad host/UI design. Once again, exact same situation if you were to make up arbitrary labels for LV2-HomeEdition. "Yeah, we forgot to tell you about the LV2-HomeEdition support... but I'm sure you'll figure that out when things don't work". No difference, you just stuck a different name on things and managed to hide information in the process since the actual missing feature is now a mystery. To make that information even useful you'd have to report the specific extension that's missing anyway. In practice, LV2-HomeEdition means nothing useful at all. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/02/2009 03:11 AM, David Robillard wrote: > On Sun, 2009-11-01 at 12:09 +1100, Patrick Shirkey wrote: > >> I'm not sure what the limitations of the existing system are but in >> general having a central location where all extensions are collated with >> explicit details about their usage and examples for how to write code >> for them them would go a long way to making the system more developer >> friendly. >> >> Providing a weekly/monthly mailout which lists the new extensions and a >> brief description with links to code examples and usage cases would also >> be helpful for developers who want to keep up to date with the latest >> offerings. >> >> Essentially spending some time on automating the notifications system >> now will be useful for everyone and could go a long way to increase the >> pickup and development rate for LV2 which is good for everyone. >> >> > The volume isn't really big enough for this, to be honest. We can set > up an RSS feed or something, or an announce list, but I really don't see > this as being an effective thing to worry about at this point in time. > I see it as being highly effective. Having a regular community wide update of useful LV2 news is a good thing (tm). For example it would be useful to have a monthly update for the wider community that is sent to the LAA list. the reason I suggest an automated letter is so that you or someone else doesn't have to manually compile the news. If LV2 really starts to take off (and it should) then we can expect to see literally thousands of plugins and extensions being produced over the coming years. Automating the process now gives us a head start. > You'd be automating nothing. Need an actual nice presentation for > extensions first, before announcing matters. > > The mailing list is low volume enough that any developers interested in > LV2 goins-on should simply be on that. I'll look into adding RSS to my > documentation generator thingie though, that's kind of a cool idea. > > The more options the merrier. >> It just so happens that I have some free time I can put aside for this >> over the next 6 weeks. If we can agree on what is missing from the >> existing system I will spend some time on integrating it. I could put >> aside 4 hours on Wed nights for this project. >> >> So, can those in the know please spend some time to think about the >> things that are currently missing from the LV2 ecosystem and I will get >> onto it. >> >> @Dave, I assume you have a feature/task list that you are working with >> so if you want to hand any specific house keeping tasks to me then fire >> away. >> > Awesome, thanks. I think the main problem right now is that the site is > stagnant. I think maybe the most feasible path, effort wise, would be > just to move all the content over to the Wiki, which is easy for > everyone to participate with, and nuke the site. > > I could probably get Steve to install Drupal or Wordpress and make a bit > more of a "professional" looking site that way, but it's more work, and > then we have two account systems instead of one. Is there any advantage > to this beyond pretty? Seems no, and adding content is a bit more > tedious. > > So maybe the best housekeepingey thing to do right now is get all the > content over to the wiki, and tidy up the wiki, then we can make it the > main page for http://lv2plug.in ? > > This won't be a problem. I can start on this process on Wed. Feel free to contact me off list about the specific items you would like to get some attention. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/02/2009 05:41 AM, David Robillard wrote: > On Sun, 2009-11-01 at 11:51 -0600, Gabriel M. Beddingfield wrote: > >> On Sun, 1 Nov 2009, David Robillard wrote: >> >> >>> But nobody needed to define MIDI+MMC and MIDI+MTC and MIDI+MMC1 and MIDI >>> +MMC2 and MIDI+MMC1+MTC and MIDI+MMC2+MTC and ... for people to make >>> sense of the whole thing, did they? :) >>> >> Yes and No. Manufacturers are required to publish their MIDI >> Implementation so that the person buying the device would know what types >> of MIDI messages the device sends and responds to. This includes the >> summarized table and the down-to-each-sysex-bit documentation. If you >> know you want an MMC-capable device, you know to look here. >> >> If you don't want to do LV2-EXtremeMakeover-HomeEdition or LV2-El33t, then >> perhaps a concise table with a standardized format might work better for >> you. >> > I agree hosts and plugins should provide this information in an easy to > find place, though doing things properly at runtime makes it less > necessary than you might think. > > That's the funny thing about this discussion. I feel that if you say it is useful but slightly unnecessary then for a lot of people it will be extremely useful :-) FWIW, I will try to bring this information out in a simple manner on the wiki. If anyone has the time to think of a detailed method for handling this please share. I will need a more advanced description of how it needs to be executed and displayed to implement this quickly. >> And, oh >> yeah, we forgot to tell you about the dynparam extension... but I'm sure >> you'll figure that out when things don't work." >> > The host has all the information needed to report this explicitly to the > user (you can't use plugin foo because this program doesn't support > feature bar). Its not like it's just going to mysteriously not work, > that's just bad host/UI design. > Is this method clearly defined in the online docs? Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
Dave, here are some observations I and probably many others made: 1) hosts are slow at picking up extensions 2) hosts mostly use just slv2 3) plugin authors are reluctant to write extensions 4) a number of plugin authors wrote their own hosts Now people see different possible reasons for this, my version is: 1,2 -> I don't know. Bad documentation? Hard to use? 3 -> 1,2 4 -> 1,2 I think that's really all there is to this discussion, a bunch of observations, different interpretations of why this is and thus different suggestions to solve the problem. So what is your variant? Best regards, Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Mon, 2009-11-02 at 07:10 +1100, Patrick Shirkey wrote: > On 11/02/2009 03:11 AM, David Robillard wrote: > > On Sun, 2009-11-01 at 12:09 +1100, Patrick Shirkey wrote: > > > >> I'm not sure what the limitations of the existing system are but in > >> general having a central location where all extensions are collated with > >> explicit details about their usage and examples for how to write code > >> for them them would go a long way to making the system more developer > >> friendly. > >> > >> Providing a weekly/monthly mailout which lists the new extensions and a > >> brief description with links to code examples and usage cases would also > >> be helpful for developers who want to keep up to date with the latest > >> offerings. > >> > >> Essentially spending some time on automating the notifications system > >> now will be useful for everyone and could go a long way to increase the > >> pickup and development rate for LV2 which is good for everyone. > >> > >> > > The volume isn't really big enough for this, to be honest. We can set > > up an RSS feed or something, or an announce list, but I really don't see > > this as being an effective thing to worry about at this point in time. > > > > > I see it as being highly effective. Having a regular community wide > update of useful LV2 news is a good thing (tm). For example it would be > useful to have a monthly update for the wider community that is sent to > the LAA list. the reason I suggest an automated letter is so that you or > someone else doesn't have to manually compile the news. If LV2 really > starts to take off (and it should) then we can expect to see literally > thousands of plugins and extensions being produced over the coming > years. Automating the process now gives us a head start. Isn't this basically what LAA is for anyway? At the end of the day the author of needs to send the announcement to /somewhere/, you can't automate news generation, it has to come from people somehow. The fully automated thing is feasible for extensions published at http://lv2plug.in/ but not much else. This is an argument for using a CMS over a wiki though. It's easy to make an RSS feed of a 'news' page and tag posts to go there. With a wiki, not so much. The only real options are wordpress and drupal since they are trivial to install on Dreamhost. > > So maybe the best housekeepingey thing to do right now is get all the > > content over to the wiki, and tidy up the wiki, then we can make it the > > main page for http://lv2plug.in ? > > > > This won't be a problem. I can start on this process on Wed. Feel free > to contact me off list about the specific items you would like to get > some attention. Don't start until we're sure this is the best plan. It's not really feasible to do the above stuff via mediawiki. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Mon, 2009-11-02 at 07:13 +1100, Patrick Shirkey wrote: > On 11/02/2009 05:41 AM, David Robillard wrote: > > On Sun, 2009-11-01 at 11:51 -0600, Gabriel M. Beddingfield wrote: > > > >> On Sun, 1 Nov 2009, David Robillard wrote: > >> > >> > >>> But nobody needed to define MIDI+MMC and MIDI+MTC and MIDI+MMC1 and MIDI > >>> +MMC2 and MIDI+MMC1+MTC and MIDI+MMC2+MTC and ... for people to make > >>> sense of the whole thing, did they? :) > >>> > >> Yes and No. Manufacturers are required to publish their MIDI > >> Implementation so that the person buying the device would know what types > >> of MIDI messages the device sends and responds to. This includes the > >> summarized table and the down-to-each-sysex-bit documentation. If you > >> know you want an MMC-capable device, you know to look here. > >> > >> If you don't want to do LV2-EXtremeMakeover-HomeEdition or LV2-El33t, then > >> perhaps a concise table with a standardized format might work better for > >> you. > >> > > I agree hosts and plugins should provide this information in an easy to > > find place, though doing things properly at runtime makes it less > > necessary than you might think. > > > > That's the funny thing about this discussion. I feel that if you say it > is useful but slightly unnecessary then for a lot of people it will be > extremely useful :-) It's useful, I just mean it's not a confusion OH GOD WHY WON'T IT WORK event if that information isn't in the documentation somewhere as was implied. Users don't actually look at that documentation 99% of the time anyway, if it /was/ a confusing event when something didn't work, that would be a problem. Luckily it is not :) That said, documentation is of course good. > FWIW, I will try to bring this information out in a simple manner on the > wiki. If anyone has the time to think of a detailed method for handling > this please share. I will need a more advanced description of how it > needs to be executed and displayed to implement this quickly. There's not really much infrastructure or detailed method involved, really. This is how it works: There are two kinds of things: plugins, hosts, and features. There are two types of relationship between plugins and features: supports, or requires. There is one kind of relationship between hosts and features: supports. Note that all of this information is trivial to extract from a plugin's data file, so compiling this kind of thing by hand is probably a really bad idea. Generated documentation is definitely the way to go. IMO non-machine-readable documentation of LV2 things is a bug in and of itself, docs should be in the .ttl and extracted into whatever human readable form is desired (including online, while the user is using things in hosts; think right-clicking a plugin or port and hitting "help") Encouraging people to host plugin bundles online and just throwing up a tool on lv2plug.in that you can point at them and get the pretty docs is probably a good idea. This is the way I am trying to encourage things with extensions - standardized bundles in a machine readable format usable by simple tools. As long as authors stick to conventions and don't make weird bundles for no reason, all this fancy documentation (and web retrieval, and whatever else) stuff is doable. > >> And, oh > >> yeah, we forgot to tell you about the dynparam extension... but I'm sure > >> you'll figure that out when things don't work." > >> > > The host has all the information needed to report this explicitly to the > > user (you can't use plugin foo because this program doesn't support > > feature bar). Its not like it's just going to mysteriously not work, > > that's just bad host/UI design. > > Is this method clearly defined in the online docs? That plugins need to provide the information in this way and host must not do "try and see if it blows up" testing for features is very explicitly stated in the docs / specification itself, yes. The docs need to be put in a more prominent place though. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Sun, 2009-11-01 at 21:36 +0100, hollun...@gmx.at wrote: > Dave, > here are some observations I and probably many others made: > > 1) hosts are slow at picking up extensions Takes time, effort. > 2) hosts mostly use just slv2 Takes less time, less effort. > 3) plugin authors are reluctant to write extensions Takes time, effort. > 4) a number of plugin authors wrote their own hosts There weren't many at the time, had to be done (chicken & egg), having multiple implementations (not all slv2) was considered a good thing. You can't claim 2 and 4 both as bad things :P > So what is your variant? Time, effort. Clearly. :) The rest is just excuses, really. What is the point in sitting here and hypothesizing about what hypothetical problems might be deterring hypothetical unnamed developers? This kind of braindead dead-end mailing list babble is exactly why LV2 has to be extensible in this way - the people who are actually about to do anything useful don't get bogged down by all the noise. There are simple, clearly defined, real, and solvable problems and tasks to do. Props to Patrick for actually stepping forward and offering to help with one of them. If more people would pick an actual, concrete problem and take it upon themselves to help out with it, then we'd be set... -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/02/2009 07:49 AM, David Robillard wrote: > On Mon, 2009-11-02 at 07:10 +1100, Patrick Shirkey wrote: > >> On 11/02/2009 03:11 AM, David Robillard wrote: >> >>> On Sun, 2009-11-01 at 12:09 +1100, Patrick Shirkey wrote: >>> >>> I'm not sure what the limitations of the existing system are but in general having a central location where all extensions are collated with explicit details about their usage and examples for how to write code for them them would go a long way to making the system more developer friendly. Providing a weekly/monthly mailout which lists the new extensions and a brief description with links to code examples and usage cases would also be helpful for developers who want to keep up to date with the latest offerings. Essentially spending some time on automating the notifications system now will be useful for everyone and could go a long way to increase the pickup and development rate for LV2 which is good for everyone. >>> The volume isn't really big enough for this, to be honest. We can set >>> up an RSS feed or something, or an announce list, but I really don't see >>> this as being an effective thing to worry about at this point in time. >>> >>> >> >> I see it as being highly effective. Having a regular community wide >> update of useful LV2 news is a good thing (tm). For example it would be >> useful to have a monthly update for the wider community that is sent to >> the LAA list. the reason I suggest an automated letter is so that you or >> someone else doesn't have to manually compile the news. If LV2 really >> starts to take off (and it should) then we can expect to see literally >> thousands of plugins and extensions being produced over the coming >> years. Automating the process now gives us a head start. >> > Isn't this basically what LAA is for anyway? At the end of the day the > author of needs to send the announcement to /somewhere/, you > can't automate news generation, it has to come from people somehow. > > The fully automated thing is feasible for extensions published at > http://lv2plug.in/ but not much else. > Ok. I will take a good look at how this can be acheived. Any suggestions for the best way to store, package and deliver the details to the news report will be appreciated. > This is an argument for using a CMS over a wiki though. It's easy to > make an RSS feed of a 'news' page and tag posts to go there. With a > wiki, not so much. The only real options are wordpress and drupal since > they are trivial to install on Dreamhost. > > >>> So maybe the best housekeepingey thing to do right now is get all the >>> content over to the wiki, and tidy up the wiki, then we can make it the >>> main page for http://lv2plug.in ? >>> >>> >> This won't be a problem. I can start on this process on Wed. Feel free >> to contact me off list about the specific items you would like to get >> some attention. >> > Don't start until we're sure this is the best plan. It's not really > feasible to do the above stuff via mediawiki. > > It's not a big deal for me to set up a drupal system for the site and move everything over to it. We can also have a wiki for documentation. However the automated system for managing plugins and details should probably be hosted on the drupal side. Does anyone know of a wiki type extension for drupal? Cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/02/2009 08:06 AM, David Robillard wrote: > On Mon, 2009-11-02 at 07:13 +1100, Patrick Shirkey wrote: > > >> FWIW, I will try to bring this information out in a simple manner on the >> wiki. If anyone has the time to think of a detailed method for handling >> this please share. I will need a more advanced description of how it >> needs to be executed and displayed to implement this quickly. >> > There's not really much infrastructure or detailed method involved, > really. This is how it works: > > There are two kinds of things: plugins, hosts, and features. > > There are two types of relationship between plugins and features: > supports, or requires. > > There is one kind of relationship between hosts and features: supports. > > Note that all of this information is trivial to extract from a plugin's > data file, so compiling this kind of thing by hand is probably a really > bad idea. Generated documentation is definitely the way to go. IMO > non-machine-readable documentation of LV2 things is a bug in and of > itself, docs should be in the .ttl and extracted into whatever human > readable form is desired (including online, while the user is using > things in hosts; think right-clicking a plugin or port and hitting > "help") > This will be a priority for me. > Encouraging people to host plugin bundles online and just throwing up a > tool on lv2plug.in that you can point at them and get the pretty docs is > probably a good idea. This is the way I am trying to encourage things > with extensions - standardized bundles in a machine readable format > usable by simple tools. As long as authors stick to conventions and > don't make weird bundles for no reason, all this fancy documentation > (and web retrieval, and whatever else) stuff is doable. > > This will be a core function of the plugins site. And, oh yeah, we forgot to tell you about the dynparam extension... but I'm sure you'll figure that out when things don't work." >>> The host has all the information needed to report this explicitly to the >>> user (you can't use plugin foo because this program doesn't support >>> feature bar). Its not like it's just going to mysteriously not work, >>> that's just bad host/UI design. >>> >> Is this method clearly defined in the online docs? >> > That plugins need to provide the information in this way and host must > not do "try and see if it blows up" testing for features is very > explicitly stated in the docs / specification itself, yes. The docs > need to be put in a more prominent place though. > > This information can be brought out into a more prominent location for all the documentation. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On 11/02/2009 08:27 AM, David Robillard wrote: > On Sun, 2009-11-01 at 21:36 +0100, hollun...@gmx.at wrote: > >> Dave, >> here are some observations I and probably many others made: >> >> 1) hosts are slow at picking up extensions >> > Takes time, effort. > > >> 2) hosts mostly use just slv2 >> > Takes less time, less effort. > > >> 3) plugin authors are reluctant to write extensions >> > Takes time, effort. > > >> 4) a number of plugin authors wrote their own hosts >> > There weren't many at the time, had to be done (chicken& egg), having > multiple implementations (not all slv2) was considered a good thing. > You can't claim 2 and 4 both as bad things :P > > >> So what is your variant? >> > Time, effort. Clearly. :) > > The rest is just excuses, really. What is the point in sitting here and > hypothesizing about what hypothetical problems might be deterring > hypothetical unnamed developers? This kind of braindead dead-end > mailing list babble is exactly why LV2 has to be extensible in this way > - the people who are actually about to do anything useful don't get > bogged down by all the noise. > Isn't that the only reason for being a member of this list? I can see that the above details could be made more obvious to the casual developer. I will work on incorporating the details into the new documentation. I'm starting to get the impression that what is really missing is not just documentation but a complete documentation system. The average developer will be coming from a proprietary world where companies have invested a lot of effort to make the documentation accessible and in addition there are several external web projects offering to fill in the gaps as it can be a good little revenue earner with advertising and google ads, etc.. I don't have much experience with the specific plugin architectures and the developer documentation that is provided but perhaps others can make suggestions of the most useful documentation features they have found while developing for alternate plugin systems? However I have been working with borland, visual studio and xcode and found several common documentation themes in those environments that we are missing round here in general. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Mon, 2009-11-02 at 08:34 +1100, Patrick Shirkey wrote: > On 11/02/2009 07:49 AM, David Robillard wrote: > > On Mon, 2009-11-02 at 07:10 +1100, Patrick Shirkey wrote: > > > >> On 11/02/2009 03:11 AM, David Robillard wrote: > >> > >>> On Sun, 2009-11-01 at 12:09 +1100, Patrick Shirkey wrote: > >>> > >>> > I'm not sure what the limitations of the existing system are but in > general having a central location where all extensions are collated with > explicit details about their usage and examples for how to write code > for them them would go a long way to making the system more developer > friendly. > > Providing a weekly/monthly mailout which lists the new extensions and a > brief description with links to code examples and usage cases would also > be helpful for developers who want to keep up to date with the latest > offerings. > > Essentially spending some time on automating the notifications system > now will be useful for everyone and could go a long way to increase the > pickup and development rate for LV2 which is good for everyone. > > > > >>> The volume isn't really big enough for this, to be honest. We can set > >>> up an RSS feed or something, or an announce list, but I really don't see > >>> this as being an effective thing to worry about at this point in time. > >>> > >>> > >> > >> I see it as being highly effective. Having a regular community wide > >> update of useful LV2 news is a good thing (tm). For example it would be > >> useful to have a monthly update for the wider community that is sent to > >> the LAA list. the reason I suggest an automated letter is so that you or > >> someone else doesn't have to manually compile the news. If LV2 really > >> starts to take off (and it should) then we can expect to see literally > >> thousands of plugins and extensions being produced over the coming > >> years. Automating the process now gives us a head start. > >> > > Isn't this basically what LAA is for anyway? At the end of the day the > > author of needs to send the announcement to /somewhere/, you > > can't automate news generation, it has to come from people somehow. > > > > The fully automated thing is feasible for extensions published at > > http://lv2plug.in/ but not much else. > > > > Ok. I will take a good look at how this can be acheived. Any suggestions > for the best way to store, package and deliver the details to the news > report will be appreciated. Probably by modifying http://drobilla.net/software/lv2specgen/ to generate an RSS feed as well. > >> This won't be a problem. I can start on this process on Wed. Feel free > >> to contact me off list about the specific items you would like to get > >> some attention. > >> > > Don't start until we're sure this is the best plan. It's not really > > feasible to do the above stuff via mediawiki. > > > > > > > It's not a big deal for me to set up a drupal system for the site and > move everything over to it. We can also have a wiki for documentation. > However the automated system for managing plugins and details should > probably be hosted on the drupal side. IMO this would probably be better off implemented as a separate script or something that has nothing to do with the CMS, so it is useful elsewhere and not tried to drupal. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
On Mon, 2009-11-02 at 08:48 +1100, Patrick Shirkey wrote: > On 11/02/2009 08:27 AM, David Robillard wrote: [...] > >> So what is your variant? > >> > > Time, effort. Clearly. :) > > > > The rest is just excuses, really. What is the point in sitting here and > > hypothesizing about what hypothetical problems might be deterring > > hypothetical unnamed developers? This kind of braindead dead-end > > mailing list babble is exactly why LV2 has to be extensible in this way > > - the people who are actually about to do anything useful don't get > > bogged down by all the noise. > > > > Isn't that the only reason for being a member of this list? Heh. Seems like it. Talking about development is like dancing about architecture, perhaps :) > I can see that the above details could be made more obvious to the > casual developer. I will work on incorporating the details into the new > documentation. > > I'm starting to get the impression that what is really missing is not > just documentation but a complete documentation system. The average > developer will be coming from a proprietary world where companies have > invested a lot of effort to make the documentation accessible and in > addition there are several external web projects offering to fill in the > gaps as it can be a good little revenue earner with advertising and > google ads, etc.. One cannot have a "documentation system" without documentation. Work on adding documentation to plugin .ttl files is definitely worthwhile, based on the assumption that someone will use it for something later. There are also many half-assed extensions that aren't marked up nicely and need this done so they can fit in and be easily/automatically well documented and consistent etc. As far as user documentation (of plugins) goes, personally I think on-line documentation in hosts is 999* more useful than any external documentation, including on the web. As for extensions and such, we just need good documentation. Can you even define "a complete documentation system" in concrete terms? ;) I'd say all that is needed beyond the automatically generated stuff is a smallish tutorial or two (some already exist) on the basics of LV2/RDF so people can understand the generated stuff. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] State of Plugin API's
Maybe it is worth looking at the extension model used in OpenGL. Extensions are at first created as something vendor specific. Widely useful extensions get reviewed by the architecture review board and if deemed worthy become arb_extensions (this is now not essential to be implemented but highly reccomended). A lot of extensions eventually find there way into the core spec. Which means that vendors have to implemented them to be compatible with that version of the OpenGL specification. Another approach might be to compile a list of stable extensions that should be supported by a host. I would suggest that such a list would be compiled once a year and that lv2_[year] could be used to suggest if a host should be expected to support a particular extension. The time period could be longer if necessary. On Tue, Nov 3, 2009 at 1:08 AM, David Robillard wrote: > On Mon, 2009-11-02 at 08:48 +1100, Patrick Shirkey wrote: > > On 11/02/2009 08:27 AM, David Robillard wrote: > [...] > > >> So what is your variant? > > >> > > > Time, effort. Clearly. :) > > > > > > The rest is just excuses, really. What is the point in sitting here > and > > > hypothesizing about what hypothetical problems might be deterring > > > hypothetical unnamed developers? This kind of braindead dead-end > > > mailing list babble is exactly why LV2 has to be extensible in this way > > > - the people who are actually about to do anything useful don't get > > > bogged down by all the noise. > > > > > > > Isn't that the only reason for being a member of this list? > > Heh. Seems like it. Talking about development is like dancing about > architecture, perhaps :) > > > I can see that the above details could be made more obvious to the > > casual developer. I will work on incorporating the details into the new > > documentation. > > > > I'm starting to get the impression that what is really missing is not > > just documentation but a complete documentation system. The average > > developer will be coming from a proprietary world where companies have > > invested a lot of effort to make the documentation accessible and in > > addition there are several external web projects offering to fill in the > > gaps as it can be a good little revenue earner with advertising and > > google ads, etc.. > > One cannot have a "documentation system" without documentation. Work on > adding documentation to plugin .ttl files is definitely worthwhile, > based on the assumption that someone will use it for something later. > There are also many half-assed extensions that aren't marked up nicely > and need this done so they can fit in and be easily/automatically well > documented and consistent etc. > > As far as user documentation (of plugins) goes, personally I think > on-line documentation in hosts is 999* more useful than any > external documentation, including on the web. > > As for extensions and such, we just need good documentation. Can you > even define "a complete documentation system" in concrete terms? ;) I'd > say all that is needed beyond the automatically generated stuff is a > smallish tutorial or two (some already exist) on the basics of LV2/RDF > so people can understand the generated stuff. > > -dr > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
