[gmpi] Re: MIDI: Proposed Reqs (try #2)
- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 13 Jul 2004 11:53:05 -0400
Here are my comments on your comments. Overall I'm happy.
I think the "1.0" needs to stay in MIDI, so that the requirements are
consistent in case somebody invents MIDI 2.0 before we finish the spec
and deliverable. So everywhere you wrote "MIDI" please use "MIDI 1.0".
>>>
Suggest:
None of the below requirements should be met by handicapping GMPI. In
particular, MIDI has well-known limitations (integer field sizes,
message
model, etc.) and those limitations should not be taken as bounds on
GMPI.
<<<
This works fo rme.
>>>
Suggest:
* It must be possible for hosts to control plugins from arbitrary
external
MIDI sources, such as hardware MIDI controllers. This includes (but
is
not limited to) playing notes, setting parameters, host-based MIDI
learn
(click-and-wiggle) and system exclusive (SysEx) messages.
<<<
OK.
>>>
* It must be possible for plugins to communicate with arbitrary external
MIDI destinations, though the in-graph data need not necessarily be
pure
MIDI). Plugins must not need to use platform-specific MIDI I/O APIs
to
achieve this.
<<<
OK.
>>>
> Req. 70: MIDI I/O BY PLUGS
I'm really confused. Isn't this covered by the previous req(s)? Or
rather,
it WOULD be covered if we took out the word "external" in them
<<<
I think the requirement is worth keeping in, if only for emphasis: GMPI
won't mean we can't write MIDI-only music processors.
>>>
> Req. 72: HW/SW STUDIO ROUTING/MANAGEMENT
I'm confused by the new term. What is a MIDI connection?
<<<
I think I know what one is, but I don't think there's anyway to discover
one unless we explicity tag control inputs as being MIDI typed.
>>>
> Req. 73: MIDI-ORIENTED MUSIC PROCESSORS
Again, I am confused. Do you want to generate MIDI or not MIDI? This
req
just isn't clear as it is put, to me.
<<<
As in req 70, I think useful to keep this for emphasis.
>>>
> Req. 74: SINGLE EVENT DELIVERY MECHANISM
My initial reaction is to disagree completely. But it's partly wording.
Maybe it would be better stated as something about "all MIDI-originated
events must be timestamped with the same timeline as any other GMPI
event"?
<<<
I think that covers the intent, except it adds complexity if we do wind
up with 2 separate delivery mechanisms. I don't see why can't build a
single mechanism for both, and since it's so attractive, to go ahead and
_require_ it.
----------------------------------------------------------------------
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:
