[LAD] State of Plugin API's
pshirkey at boosthardware.com
Sun Nov 1 21:39:41 UTC 2009
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
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.
Boost Hardware Ltd
More information about the Linux-audio-dev