[gmpi] Re: 3.15 MIDI (What does it mean to be a plugin)
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 18 Jun 2004 15:04:33 -0700
Your big post is very useful, thanks Mike. I need to think about
your request for examples more, but meantime I wanted to comment on a
few of the premises, mainly here:
I am more worried about the matrix of complexity and compatibility
that results from having 3 fundamental types instead of 2, than for
the lost possiblity of writing MIDI bytestream specific plugins.
and here:
...let me expose what, to me, are the two counterbalancing arguments:
- If we have MIDI as a format, then plugins can be written which
explicitly exploit the MIDI byte stream in some way.
- If we support MIDI and GMPI control data as separate types, then
we dilute the potential compatibility of GMPI hosts and plugins.
Some people will choose to write plugins which only take MIDI
control, not because of inherent MIDI bytestream characteristics,
but just because it is familiar. Some will write plugins that only
handle GMPI control data because it is more flexible or easier to
understand than MIDI or whatever their reason is. These plugins will
not be able to exist in the same graph without translation
(host-based or other plugin based).
Right now, I think that the second consideration outweighs the first.
1. There is a proposal for making MIDI Message not a second control
type, but a GMPI parameter datatype. So it wouldn't necessarily be
audio + GMPI control + MIDI control, but might be audio + a GMPI
control which can encapsulate MIDI among other things. So the
parameter datatypes list could become { real number, integer, string,
enumerated list, boolean value, opaque data, and opaque MIDI message
}.
2. (Main point:) If that approach were taken, it would likely have an
essentially blob-like form. The group earlier accepted that blob
parameters could exist despite their semantics being opaque to the
host, and despite the fact that blob receipt might change plug state
in arbitrary ways, including overlapping with exposed GMPI
parameters. So from this POV it seems like the NMiG folks are saying
that opaque-to-the-host data is acceptable when we label it blob, but
unacceptable when we label it MIDI, a distinction I find difficult to
understand.
3. Motivations for having mainly or solely MIDI-driven plugs in GMPI,
especially at first, are probably somewhat more weighty than just
familiarity. There may be perceived commercial issues of
customer==market expectation, incremental development cost avoidance,
complexity avoidance, fear of introducing incompatibility with the
installed MIDI world, and multi-plug-format fatigue... some of which
may be illusory, but that doesn't lessen their effect on plug
developers' decision process. So I think this, though not in itself
conclusive, should factor into the balancing.
4. I'm vague on to what extent you considered MIDI out in your
analysis, can you comment?
Hope you sleep better tonight,
-- Chris G.
----------------------------------------------------------------------
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:
