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