[gmpi] Re: MIDI: Proposed Reqs (try #3)

Sorry for the confusion...

On Wed, Jul 14, 2004 at 11:51:47AM -0700, Chris Grigg wrote:
> Read the inserted comments.

This seems long, but it's mostly quoted...

> > 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.  The GMPI system can and should provide richer and more
> > detailed information than MIDI is capable of.  However GMPI must still
> > interoperate with MIDI.
> 
> That needs to be tightened up quite a bit, where did the guarantees
> about lossless performance etc. go?

That's included below in the reqs.  The prolog (which we should probably
have for each section) should maybe provide a brief introduction to the
section.  That's all I wanted.  The prolog was not intended to be the
executive summary of the reqs, and you still need to comprhend the reqs to
grok any particular section.  I'll update it to say "interoperate
losslessly".

> > Use case: A hypothetical instrument plugin is literally the same code that
> > is running on a hardware synth, with a small GMPI wrapping.  The developer
> > wants to keep the core code as common as possible.  This core code already
> > handles MIDI and the developer does not want to change it.  This plugin can
> > elect to receive raw MIDI.
> 
> ??? -- This is completely new. What can "raw MIDI" mean, if not that to
> which you are opposed?

I thought this was an established use case.  OK, "raw MIDI" is wrong What
about "This plugin can elect to be driven by MIDI" or "This plugin can
elect to receive only MIDI-compatible messages"?  What if I just left off
the last sentence (This plugin can...).?

> Label this 'Click and Wiggle' for clarity

Will do

> > * It must be possible for plugins to communicate with arbitrary external
> >   MIDI destinations
> 
> Need to disambiguate 'arbitrary external MIDI destinations'.

What about:  "It must be possible for plugins to send MIDI to arbitrary
desitinations outside the host" ?

> >     * It must be possible for plugins to operate as 
> 
> What does 'operate as' mean?

You wrote "It must be possible for plugs to effectively behave as MIDI 1.0
receivers and/or senders".  "operate" means the same as "effectively
behave".  'Operate' suggests (to me) that they *are* doing MIDI I/O, whereas
'effectively behave' suggests (to me) that they are doing I/O that is MIDI
compatible, but might tnot be MIDI.  I thought it was a requirement that
plugins be able to ACTUALLY BE MIDI processors?

Happy to change it - do you prefer 'effectively behave' ?

> > Use case: A hypothetical plugin is a MIDI transposer.  It receives raw MIDI,
> > transposes it by some user-defined amount, and then emits MIDI.
> 
> ??? - Again you put receiving raw MIDI into the reqs, which I
> strenuously avoided. Reasoning please?

It was my understanding that this was a requirement.  The stapling
proposal (which is just one option) leads me to believe that such a
plugin would only operate on messages with the MIDI message stapled.
Thus, I believed that the intent was to handle MIDI.

What if I change "raw MIDI" to "MIDI-compatible messages" ?

> > Req. 72: HW/SW STUDIO ROUTING/MANAGEMENT - It must be possible to
> > effectively route MIDI 1.0 connections  (though the in-graph data
> > need not necessarily be in pure MIDI 1.0 format) between proxied MIDI
> > HW devices and/or other GMPI plugins in the same GMPI graph, using only
> > //FIXME: need clarity!
> 
> I saw your other postings on this and do not see what's not to
> understand, can you clarify?

What is a "MIDI connection" ?  Do you mean that it must be possible to use
a GMPI graph as a complex patch-panel?  Maybe a hypothetical use case
would clarify for me?

> > * All MIDI-originated events must be timestamped on the same timeline as
> >   all GMPI events.  The actual MIDI event mechanism might or might not be
> >   built atop the GMPI event mechanism.
> 
> ??? - This throws out all of Mike's concerns. Nobody is arguing for
> separate delivery mechanisms. Where did this come from, what's your
> motivation?

The motivation the realization that even with MIDI as a first order
entity, it is possible to use a GMPI->MIDI wrapper and use it for plugins
that need it, FLStudio being the example raised.  That, combined with some
of us in NMiG finding 'stapling' distasteful led to a brief discussion
doing it that way.

Is this worth leaving wiggle room in the reqs and discussing further?
Maybe a More Info section to cover this very justification?

> >   transcoding incoming MIDI (1.0) messages to GMPI events, and for
> >   transcoding (with managed loss) outgoing GMPI events to MIDI (1.0)
> 
> Drop "(1.0)", redundant to new intro.

Done.

Sorry for the confusuion - I did not read past your signature line when I
first replied.  My fault.  Thank you for your patience.

Tim
(this space intentionally left blank)

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: