On Mon, 2009-11-02 at 07:13 +1100, Patrick Shirkey wrote: > On 11/02/2009 05:41 AM, David Robillard wrote: > > On Sun, 2009-11-01 at 11:51 -0600, Gabriel M. Beddingfield wrote: > > > >> On Sun, 1 Nov 2009, David Robillard wrote: > >> > >> > >>> But nobody needed to define MIDI+MMC and MIDI+MTC and MIDI+MMC1 and MIDI > >>> +MMC2 and MIDI+MMC1+MTC and MIDI+MMC2+MTC and ... for people to make > >>> sense of the whole thing, did they? :) > >>> > >> Yes and No. Manufacturers are required to publish their MIDI > >> Implementation so that the person buying the device would know what types > >> of MIDI messages the device sends and responds to. This includes the > >> summarized table and the down-to-each-sysex-bit documentation. If you > >> know you want an MMC-capable device, you know to look here. > >> > >> If you don't want to do LV2-EXtremeMakeover-HomeEdition or LV2-El33t, then > >> perhaps a concise table with a standardized format might work better for > >> you. > >> > > I agree hosts and plugins should provide this information in an easy to > > find place, though doing things properly at runtime makes it less > > necessary than you might think. > > > > That's the funny thing about this discussion. I feel that if you say it > is useful but slightly unnecessary then for a lot of people it will be > extremely useful :-)
It's useful, I just mean it's not a confusion OH GOD WHY WON'T IT WORK event if that information isn't in the documentation somewhere as was implied. Users don't actually look at that documentation 99% of the time anyway, if it /was/ a confusing event when something didn't work, that would be a problem. Luckily it is not :) That said, documentation is of course good. > 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. > >> 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. -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
