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

Sorry, no time for a full reply today, will reply as soon as I can.

There are a lot of new ideas that don't reflect the discussion to date -- why?

Are we to assume all *'s are meant as numbered reqs?

        -- Chris G.

> I'm working an another draft, and I *really* need you and others to read
it, and feedback. I'll try to make it right, this time. 

As promised.  Please PLEASE feedback.  Please let's wrap this up.


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


  All references to "MIDI" in this section refer to the MIDI 1.0 standard,
  as defined by the MMA.

* It must be possible for hosts to control plugins from arbitrary external
  MIDI sources, such as hardware MIDI controllers or other MIDI software.
  This includes (but is not limited to) playing notes, setting parameters,
  host-based MIDI learn (click-and-wiggle) and system exclusive (SysEx)
  messages.

More:

  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?


Use case: 

Label this 'Click and Wiggle' for clarity

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.

Use case: 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.

* It must be possible for plugins to communicate with arbitrary external
  MIDI destinations


Need to disambiguate '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.

* It must be possible for plugins to operate as 

What does 'operate as' mean?


MIDI receivers, processors,
  and/or senders (though the in-graph data need not necessarily be
  pure MIDI).

  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 must be possible for a GMPI plug to act as a proxy for a connected
  hardware MIDI device (though the in-graph data need not necessarily be
  pure MIDI).

  Use case: 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.

//FIXME: need clarity! 
 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

 > the GMPI API.
//FIXME: need clarity!

I saw your other postings on this and do not see what's not to understand, can you clarify?


* 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 GMPI event system must be able to represent all MIDI messages
  without any loss of information, including message content and time.  An
  initial proposal for a single, common event coding has been drafted
  <link>.

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


Drop "(1.0)", redundant to new intro.


  Depending on the eventual design of the pure GMPI note 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,
  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's limited integer fields.  System Exclusive messages
  must always be passed verbatim, with no transcoding.

* Plugins which intend their parameters to be driven by MIDI must be able
  to expose to the host a mapping of MIDI messages to parameters.  The map
  must be changeable at runtime, for example when the parameter set
  changes.

More:

  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.

* Plugins with MIDI-driven parameters, where changes to one parameter
  automatically produce changes in other parameters, must use an Actor to
  properly model any parameter linkages.

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



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