1 Nov
2009
1 Nov
'09
5:40 p.m.
On 11/02/2009 08:06 AM, David Robillard wrote:
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
On Mon, 2009-11-02 at 07:13 +1100, Patrick Shirkey
wrote:
This will be a priority for me.
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.
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.