1 Nov
2009
1 Nov
'09
4:14 p.m.
On 11/02/2009 05:41 AM, David Robillard wrote:
Is this method clearly defined in the online docs?
Patrick Shirkey
Boost Hardware Ltd
On Sun, 2009-11-01 at 11:51 -0600, Gabriel M.
Beddingfield wrote:
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 :-)
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.
On Sun, 1 Nov 2009, David Robillard wrote:
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.
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.
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.