[LAD] State of Plugin API's

Patrick Shirkey pshirkey at boosthardware.com
Sat Oct 31 22:44:15 UTC 2009


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 at drobilla.net>  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







More information about the Linux-audio-dev mailing list