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

OK, here's a whack at MIDI requirements; sorry for the time-lag, I'm overbooked currently.

Rather than line-by line commenting on Tim's first whack (quoted way below for reference), I've gone at it from scratch because there seemed to be more parts, and it felt like a different structure was 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.

I hope I didn't miss anything. As written, this is all orthogonal to the stapling issue.

Have at,

        -- Chris G.

3.15. MIDI

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.

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.

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.

MORE: One option is to allow for MIDI->GMPI (& vice versa) converter plug-ins.

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.

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.

MORE: This is meant to promote host functionality like the Environment in Logic.

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.

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

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

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.

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.

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

..end..


Woops, I meant to change the subject...

On Wed, Jun 23, 2004 at 02:26:25PM -0700, Tim Hockin wrote: 
 So how can we encapsulate what we've been discussing into requirements?
 Obviously, Chris' proposal (with updates as discussed since then, right
 Chris :) will be included or linked to in the More Info section.



Proposed reqs for Section 3.15 "MIDI".  I am sure there are more that are
needed, and some rewording.  Suggestions?


* GMPI must provide complete interoperability with MIDI controllers.  It
  must be possible to control plugins within a GMPI graph with MIDI input.
  MIDI input must be sent through the host like all GMPI events.

  MORE:  For every MIDI message, there must be a corresponing parallel in
  GMPI.  It must be possible to losslessy transcode a MIDI event into a
  GMPI event and back. A basic proposal covering the details of this
  transcoding has been developed. <link>

* Plugins must be able to expose a preferred MIDI map, which allows the
  host to configure some automatic MIDI control of the plugin.

  MORE:  It's probably OK to limit this MIDI map functionality to the
  following MIDI messages: 7-bit CC, 14-bit CC, RPN, NRPN, note-on,
  note-off, pitchbend, channel aftertouch, and poly aftertouch.

* Plugins must be controllable through host-based MIDI-learn.  This allows
  the host to map any incoming MIDI controller to any parameter.

  MORE:  This is "click and wiggle" functionality.  The user selects a
  parameter, then sends a MIDI controller message.  That MIDI control is
  bound to the specified parameter.  It's probably OK to limit this
  functionality to the following MIDI messages: 7-bit CC, 14-bit CC, RPN,
  NRPN, note-on, note-off, pitchbend, channel aftertouch, and poly
  aftertouch.

* It must be possible for GMPI plugins to receive MIDI SysEx messages.
  GMPI hosts must not modify SysEx messages in any way.

* It must be possible for plugins to send MIDI.

  MORE:  One possible mechanism for plugins to send MIDI is for hosts to
  provide a GMPI->MIDI output plugin.  Another possible option is for GMPI
  to define a host-based API for accessing virtualized MIDI outputs.

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