State of Plugin API's

[Gabriel M. Beddingfield]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[hollunder]

On Wed, 28 Oct 2009 08:50:34 -0500 (CDT)
"Gabriel M. Beddingfield" <gabriel@...> 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Nedko Arnaudov]

"Gabriel M. Beddingfield" <gabriel@...> 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 <GnuPG KeyID: DE1716B0>


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Jörn Nettingsmeier-6]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Gabriel M. Beddingfield]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Emanuel Rumpf-2]

2009/10/28 Jörn Nettingsmeier <nettings@...>:
> 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Sean Bolton-2]

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
<fill-in-the-blank>.  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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Fons Adriaensen-2]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Sat, 2009-10-31 at 17:35 +0100, fons@... 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Paul Davis]

On Sat, Oct 31, 2009 at 1:40 PM, David Robillard <dave@...> wrote:

> On Sat, 2009-10-31 at 17:35 +0100, fons@... 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Sat, 2009-10-31 at 14:05 -0400, Paul Davis wrote:

> On Sat, Oct 31, 2009 at 1:40 PM, David Robillard <dave@...> wrote:
> > On Sat, 2009-10-31 at 17:35 +0100, fons@... 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Paul Davis]

On Sat, Oct 31, 2009 at 3:12 PM, David Robillard <dave@...> 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote:

> On Sat, Oct 31, 2009 at 3:12 PM, David Robillard <dave@...> 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 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.

Maybe.  If he didn't get all trolley and call the whole thing a
catastrophic failure then maybe I would have focused on that part ;)

Arguments about this at a high level are almost entirely pointless
anyway: developers who are actually going to solve the problems will
show up and do so.  The kind of people who whine on mailing lists about
it or make up sociological arguments for the lack of this and that
aren't the sort of people who are actually about do it anyway, so who
cares what they think?  What could actually be done to magically make
people show up who will do this work?  Nothing.  A developer who is
interested in making e.g. ramped control ports will show up, or they
won't.  The whole thing simply has to grow, which is the only realistic
way to solve a problem like this anyway.

How about this: just pretend LV2 IS a monolithic specification!
Therefore, it does not exist in a finished state yet (just as it
wouldn't), and there is no such thing as LV2.  There is no technological
difference between this and reality.  If you want to define "the LV2
specification" in your mind as some bloated and completely arbitrary
kitchen sink of features, feel free to do so and consider the entire
thing unfinished and not worthy of implementation at all.  Call
extensions "working groups" or whatever to satisfy your bureaucratic
leanings.  Is this stupid?  Sure it is.  But that's basically my
point :)

Obviously I agree things need to be done, but whining about the entire
thing at the meta level is not what needs to be done.  Extensions are
(well, should be) tidy little bits of well-defined functionality.  When
there is a hole, as you said, you make one, you implement it, and the
problem is solved.  As people scratch those itches, all the problems
will be solved.

Itch scratching solves problems, FUD and whining doesn't.  Itch
scratching is pretty much the ONLY thing that solves problems around
here anyway.  LV2 is simply optimized to exploit this fact of reality as
efficiently as possible, and it's worked pretty well so far.  There is
no committee to point fingers at, because you can implement whatever you
like.  The only place to point that finger is at yourself.

This way, things get designed and implemented by people who actually
give a damn about those things.  The end result is quality software.
Calling the whole thing a catastrophic failure is, frankly, complete and
utter bullshit, and spreading that kind of opinion only HURTS progress.
Someone may skim through the list, see that, and decide that LV2 is a
failure and thus not worth investing in or implementing, which is
completely untrue (and happens).  I call it FUD for a reason, it damages
LV2 in exactly the same way a certain notorious company damages others
with FUD.  People not actively helping doesn't really irk me so much -
but people doing this certainly does.  LV2 is no failure, but keep
sabotaging it in that way and maybe it will be.  Pointing out that the
community engineering aspect is a failure and then doing precisely the
thing that damages it the most is a teeny bit hypocritical, isn't it?

There is no inherent problem with LV2, there are only jobs to do - and
they will get done, eventually.  Most likely by people who spend more
time typing into their text editors than their email clients.  End of
story.

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Patrick Shirkey]

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<dave@...>  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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Gabriel M. Beddingfield]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Jörn Nettingsmeier-6]

David Robillard wrote:
<many, many things>


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 <a></a>, 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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Patrick Shirkey]

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@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Paul Davis]

On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
<pshirkey@...> wrote:

   [ ... stuff .... ]

the idea occured to me sometime today.

"my host supports LV2-E1"
"my plugin requires LV2-E2"
"this application uses LV2-E<N>"

EV<N> = LV2 core + { extA, extB, extC .. }

its not a new idea, i'm just "naming" it.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Patrick Shirkey]

On 11/01/2009 02:38 PM, Paul Davis wrote:

> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
> <pshirkey@...>  wrote:
>
>     [ ... stuff .... ]
>
> the idea occured to me sometime today.
>
> "my host supports LV2-E1"
> "my plugin requires LV2-E2"
> "this application uses LV2-E<N>"
>
> EV<N>  = 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<N> is a unique number?


Cheers.



Patrick Shirkey
Boost Hardware Ltd


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev