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

On Tue, Jul 06, 2004 at 06:01:12PM -0700, Chris Grigg wrote:
> needed.  Also, I know the phrase "(though the in-graph data need not 
> necessarily be in pure MIDI 1.0 format)" appears way too many times, 
> but that's just to be super-clear from the start -- since there's so 
> much sensitivity and confusion about what MiG vs. NMiG means any 
> more; I expect them to be mostly struck later.

ok, here's my thoughts..

> Req. 68: NO DRAG ON PURE GMPI - In general, none of the following 
> MIDI requirements should be met by handicapping the abstract design 
> of other, non-MIDI-related, 'pure GMPI' requirement areas; in 
> particular, MIDI's well-known limitations in terms of integer field 
> sizes, message model, etc. should not be taken as bounds on GMPI per 
> se.

The wording on this confuses me.  A rule of thumb I was taught for reqs -
simple language is more likely to be correct.

It seems like this section (and some others) could use a short prolog to
describe the goal of the section of reqs.  The above (simplified) should
be the prolog.  Any objections?

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.

> Req. 69: EXTERNAL MIDI IN & OUT - It must be possible for hosts to 
> control plugs from arbitrary MIDI 1.0 HW instrument controllers, HW 
> control surfaces, and SW outside the GMPI graph (though the in-graph 
> data need not necessarily be in pure MIDI 1.0 format).  This includes 
> but is not limited to playing notes, adjusting parameters, host-side 
> ad hoc 'click-and-wiggle' controller mappings, and System Exclusive 
> communication. It must also be possible for plugs to communicate to 
> arbitrary external MIDI devices (including other SW outside the GMPI 
> graph) by effectively emitting MIDI 1.0 for the host to route to 
> destinations outside the GMPI graph (though the in-graph data need 
> not necessarily be in pure MIDI 1.0 format). Plugs must not need to 
> use platform native MIDI I/O APIs to achieve this, it must be 
> possible using only the GMPI API.

Lotsa words.  Can it be simplified?  Do we really need to call out MIDI as
"MIDI 1.0"?  Do we need to distinguish "MIDI instrument controllers" from
"control surfaces"?  Also, these should be two reqs.  Being controllable
by MIDI and emitting MIDI are really not necessarily related.

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.

* 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.

> Req. 70: MIDI I/O BY PLUGS - It must be possible for plugs to 
> effectively behave as MIDI 1.0 receivers and/or senders (though the 
> in-graph data need not necessarily be in pure MIDI 1.0 format) using 
> only the GMPI API.

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

> Req. 71: MIDI HW PROXIES - It must be possible for a GMPI plug to act 
> as a proxy for a connected hardware MIDI device in the studio (though 
> the in-graph data need not necessarily be in pure MIDI 1.0 format) 
> using only the GMPI API.

I think this is somewhat vague, but I see no problem with it.

> 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 plugs in the same GMPI graph, using only 
> the GMPI API.

I'm confused by the new term.  What is a MIDI connection?

> Req. 73: MIDI-ORIENTED MUSIC PROCESSORS - It must be possible to 
> effectively generate and process MIDI 1.0 streams (though the 
> in-graph data need not necessarily be in pure MIDI 1.0 format) with 
> GMPI plug-ins, using only the GMPI API.  E.g. transposers, 
> channelizers, splitters, strummers, etc. that operate on just a 
> control stream, not audio; or e.g. generators like software LFOs.

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.

> Req. 74: SINGLE EVENT DELIVERY MECHANISM - To preserve 
> sample-accurate timing and simplify automation state repeatability, 
> there must not be a separate message routing system for 
> MIDI-originated events; all MIDI-originated events must be 
> communicated to plugs, and from plugs to other plugs or the host, via 
> the same control signal system described in sections 3.8. Events, 
> 3.11. Parameters, and 3.12 Control I/O  (though the in-graph data 
> need not necessarily be in pure MIDI 1.0 format).

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"?

My reasoning is this:  In the stapled model, there is only one event,
which is GMPI+MIDI.  But I am not ready to rule out a model where MIDI is
a first-class citizen, and is delivered seperately from GMPI events.

> Req. 75: SINGLE EVENT CODING - To simplify automation state 
> repeatability, in addition to representing all pure GMPI event types, 
> the GMPI event system must also be able to represent all MIDI 1.0 
> messages absolutely without loss of information (message content and 
> time) (though the in-graph data need not necessarily be in pure MIDI 
> 1.0 format).  An initial proposal for a single, common event coding 
> intended to meet the needs of both MIDI 1.0 and all expected pure 
> GMPI messages has been drafted <link>.

fine.

> Req. 76: DEFINED TRANSCODING - GMPI must include a single, clear, 
> universal rule set for losslessly transcoding incoming MIDI 1.0 
> messages to GMPI events, and for transcoding (with managed loss) 
> outgoing GMPI events to MIDI 1.0 messages. Transcoding must occur at 
> the MIDI 1.0 message level, not the individual MIDI byte level.
> 
>       MORE:
>       * Depending on the eventual design of the pure GMPI note
>       representation event(s), the relationship between MIDI messages
>       and GMPI events may not necessarily always be 1:1.
>       * For outgoing
>       GMPI events that are transcoded to MIDI 1.0, the rules will need
>       to exactly specify what truncation, rounding, etc. operations are
>       needed when converting float or other high-resolution GMPI
>       values to MIDI 1.0's limited integer fields.
>       * System Exclusive
>       messages must always be passed verbatim, with no transcoding.

This whole req should be the "more" for your #75

> Req. 77: MIDI-PARAMETER MAPPING - Plugs with MIDI-driven parameters 
> (in the sense of section 3.11 Parameters) must be able to expose to 
> the host an arbitrary MIDI-messages-to-parameters map.  The map must 
> be changeable at runtime, for example when the parameter set changes.

Fine.  How about a use case:

* In a hypothetical host, the user can define which MIDI ports/channels
  are to be delivered to a specific plugin instance.  The plugin publishes
  a MIDI map.  When the host receives MIDI on those ports/channels, the
  host can convert the incoming MIDI into GMPI messages, which can be
  delivered directly.  The plugin does not need to handle pure MIDI, yet
  it can be driven by pure MIDI.

> Req. 78: MIDI AND ACTORS - For plugs with MIDI-driven parameters (in 
> the sense of section 3.11 Parameters) where changes to one parameter 
> via MIDI automatically produce changes in other parameters, all such 
> links must be correctly modelled by the plug's Actor component (per 
> section 4.21 The Parameter Pre-Processor Model).

Agree.

At the risk of beating this to death and beyond, I want to re-categorize
your re-categorization of my reqs.  I think we're both off, but getting
asymptotically closer.

Before we try to lump these into semi-phrased requirements, let's write
them out in plain English.  This is my understanding of ALL the things
we've talked about wrt MIDI (unless I forgot some).  Doe anyone have
anything to remind me of or to argue with?

-----------------

Before anything, it is important to point out that GMPI should not be
bounded by the well-known limitations of MIDI.  The GMPI
protocol/messages/events can and should provide richer and more detailed
information than MIDI is capable of.  However GMPI must still interoperate
with MIDI.

There must be a way to control plugins from MIDI.  That MIDI might come
from a hardware MIDI controller, from some other piece of software, or
from another plugin.  Plugins should not know or care what the source was.

More specifically, there are three ways a plugin might be controlled by
MIDI.

First, a plugin might want to receive pure MIDI.  The "stapling" proposal
covers this, as does a MIDI-input-port model.  Plugins must be able to do
this through GMPI, without platform-specific mechanisms.  Regardless of
how MIDI is actually delivered to a plugin, the MIDI messages must be
timestamped from the same timeline as all GMPI events.

Second, a plugin might want to receive only pure GMPI, but expose a
semi-static map of MIDI messages to GMPI messages.  This map is
semi-static, because it might change if the parameter list or channel
structure changes.  For any MIDI messgae that can be received, there must
be a GMPI equivalent to which it can map (so that plugins can achieve the
exact same effect as receiving pure MIDI). The literal message mapping
might not be 1:1, but it must be well defined for all cases.

Third, a plugin might want to receive only pure GMPI, and not define any
particular MIDI map.  The host can do MIDI-learn for the plugin, if it has
that as a feature.

In any of those cases, the plugin might still want to receive MIDI SysEx
messages.  These must be special, and there must be a way for any plugin
to receive these.

There must be a way for plugins to produce MIDI.  That MIDI might be
destined for a piece of MIDI hardware, another piece of software, or
another plugin.  Plugins must be able to do this through GMPI, without
platform-specific mechanisms.  Plugins should not know or care what the
destination is.

These are several use cases, depicting these ideas:

1) 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.

2) In a hypothetical host, the user can define which MIDI ports/channels
  are to be delivered to a specific plugin instance.  The plugin publishes
  a MIDI map.  When the host receives MIDI on those ports/channels, the
  host can convert the incoming MIDI into GMPI messages, which can be
  delivered directly.  The plugin does not need to handle raw MIDI, yet
  it can be driven by MIDI.

3) In a hypothetical host, the user can define which MIDI messages affect
  a specific plugin instance and how.  The user can select a parameter and
  instruct the host to do a MIDI learn.  The user can then cause a MIDI
  message to be sent to the host, for example by moving a knob on a
  controller.  The host can map that MIDI message to the specified
  parameter.  The plugin does not need to handle raw MIDI, yet it can be
  driven by MIDI.

4) A hypothetical instrument plugin is a software version of a hardware
  synth.  The plugin can accept SysEx messages that are identical to the
  hardware synth, and behave similarly.

5) A hypothetical plugin acts as a MIDI proxy for a hardware synth.  The
  user can interact with the software interchangeably with the hardware.
  This plugin might choose to receive raw MIDI, or might provide a robust
  MIDI map.  This plugin can also emit MIDI, which can be routed to the
  hardware synth.

6) A hypothetical plugin is a MIDI transposer.  It receives raw MIDI,
  transposes it by some user-defined amount, and then emits MIDI.
  
---------------------------

----------------------------------------------------------------------
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: