[gmpi] Re: Requirements evaluation
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 8 Nov 2003 18:26:17 -0800
On Sat, Nov 08, 2003 at 07:08:14PM -0700, eric wrote:
> It sounds to me like the idea of using thin layers is already effecting
> the design. For instance, handling an instrument interface
Yes, and I'm trying to find proper way of expressing this in requirements,
without going too far.
Some sets of controls and/or callbacks can be grouped into various
'interfaces'. Plugins which implement those controls/callbacks can be said
to implement the interface (see note 1).
Is it necessary for a plugin to declare 'I support interface X'?
If so, how?
If a plugin partially implements an interface, does it implement the
interface?
Is it necessaru tp define these interfaces outside of the GMPI spec? That
is, do we allow a vendor to define interface Foo, and have plugins implement
foo?
If so, how do they define that?
Note 1: Controls/parameters are already a dynamic 'list' of things, so
implementing a control is as simple as adding it to your list. If we allow
interfaces to encompas callback, we mandate a dynamic callback mechanism.
Either something which allows you to query a callback struct for each
interface, like:
interface_ops = plug->get_interface("Foo");
interface_ops->do_something(arg);
Or something which multiplexes all callbacks, like:
plug->callback("Foo.do_something", arg);
> * description - provide a method whereby a plugin can describe its
> interface and capabilities to the host
Of course, this one is obvious.
> * wrapping - provide a mechanism through which a single library can
> provide multiple plugins (assuming that machines can be added
> dynamically, this could be used for plugin wrappers)
Got that one
> * discovery - combine the simplicity of a directory search with the
> speed benefits of a central plugin db (assuming that these plugin
> descriptions can be expressed in an XML file and stored in a central
> location for easy plugin management)
A central DB requires privileged access. A requirement for systems like
Linux is that GMPI plugins can be installed personally by a user.
> >OK. I've been referring to these things as weel-known parameters.
> >Essentially (my draft reqs should make this clear) anything that is not
> >mandatory is a Control (a better name for parameter).
> >
> Are we sure that control is a better name for a parameter? What is your
> thinking?
I thnk it is. A Parameter is too mathematical by connotation. I have been
unable to get any significant response to this. Further, I think parameter
is already overloaded, so choosing a new name will help people keep GMPI and
other APIs clear. Controls are any non-data signal. Clock, MIDI, knobs,
opaque blobs. Can you find a better word? Controls can be input or
output. Fundamentally there isn't much different between a control source
and a control sink, except the direction.
> My current understanding of the vocabulary is taken from the unofficial
> GMPI summary document:
>
> [Parameters have all sorts of meta-data, such as datatype, range, etc.
If I have my way, substitute 'Control' for 'Parameter'.
> What is your definition of a control, and how does it fit into this
> vocabulary? Do you think it will be confusing to have a control *and*
> control-input / control-output?
If will simplify it. All Parameters are input or output.
> How will the user know that s/he can send aftertouch if the plugin does
> not declare somewhere that it supports it?
It does - it exposes it's Controls. The host will notice the aftertouch
control and can send MIDI aftertouch signal to it.
> >Actual design and encapsulation will come later. First we do reqs. THEN
> >the spec.
> >
> Agreed, but it's difficult to discuss requirements without providing a
> few examples of use-cases and how a solution might satisfy the
> requirement. It helps to put us all on the same page.
Agreed, and it helps us to believe the requirements are legit.
> Whatever runtime we decide to use (or build), it should be available for
> free download (with source) for host developers on all of the major
> platforms, and usable for commercial, open-source, and free
> closed-source applications.
Agreed - the GMPI SDK should be totally free, in this sense.
> >It all depends whether it is optional or not ;) It seems like a great
> >candidate for a well-known control, but it doesn't need to be timestamped.
> >If this notification mechanism is non-optional, then it should not be a
> >parameter.
> >
> Why make a distinction between a parameter and a control? I'm not clear
> on this point yet...
Sorry, I mixed terminology.
> >Not if it adds much complexity. I'd need to see some ideas about how to do
> >it with minimal work before I agree it's required. Desired, sure.
> >But required?
> >
> This is not something that I can simply glance over easily. If we are
> going to enable backwards compatability with a future version of GMPI
> that might allow it, we need to abstract it here and now (v1). In other
> words, in the future, if/when it does become abstracted, support for
> GMPI V1 plugins will be a wicked hack at best, and I don't mean that in
> a good way.
I don't think most of us want extensible IO datatypes. It's a BIG pain.
Extensible parameter types? Well, we have that in opaque types, now.
> >Maybe. I'm not convinced it is needed. A plugin announces it's
> >capabilities by exposing it's controls. When the host enumerates the
> >controls, it notices, HEY! That's a MIDI-compat control.
> >
> In that case, we may need to add a little more meta data to
> parameters... type and protocol if I'm understanding you. Should it be
> possible to support more than one protocol on a single control? I think
> so.... at least, I don't see a good reason to restrict the possibility.
> In this case, I think it would be a cleaner solution to declare
> capabilities separately. It just feels like a cleaner solution to me.
Eh? There is no protocol but GMPI. a MIDI comptible control will receive
GMPI events. It is MIDI compat because it has indicated to have a
well-understood meaning. That allows the host (or a plugin) to convert MIDI
input (a file or MIDI device) to GMPI events, and send them to the plugin.
Plugins in GMPI can be MIDI compatible without ever touching MIDI.
> >I'm not convinced. This may be a red-herring for now. Does something like
> >this need to be in the reqs?
> >
> I think it should be addressed and decided before the reqs collection is
> closed. You say your not convinced that it's needed. I'm not convinced
> that it's not needed.
Fair enough
> I think these definitions should be clarified so everybody is on the
> same page. Maybe my next doc should be a GMPI vocabulary page. =)
A glossary is on my TODO list :) I'm trying to get the right terms decided.
Like Parameter vs. Control. I just want to know if everyone will make me
change it back, if I change it. :)
Tim
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
