[LAD] State of Plugin API's

[David Robillard]

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.

> 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.

Once again, exact same situation if you were to make up arbitrary labels
for LV2-HomeEdition.  "Yeah, we forgot to tell you about the
LV2-HomeEdition support... but I'm sure you'll figure that out when
things don't work".  No difference, you just stuck a different name on
things and managed to hide information in the process since the actual
missing feature is now a mystery.  To make that information even useful
you'd have to report the specific extension that's missing anyway.  In
practice, LV2-HomeEdition means nothing useful at all. 

-dr