[gmpi] Re: MIDI: Proposed Reqs (try #2)
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 6 Jul 2004 21:09:38 -0400
Thanks, I think this is a much clearer specification of the real
requirements.
----- Original Message -----
From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, July 06, 2004 9:01 PM
Subject: [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: //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: //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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
