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

What is you position w.r.t the status of the native GMPI and MIDI
(OSC, watever) source?

ie. which are compulsory and which optional.

- Steve


?? - This thread is about requirements. Like I said:
As written, this is all orthogonal to the stapling issue.

If you really need some expansion on that, then: I'm tending to agree with whoever suggested that stapling can be seen as an optimization (i.e., the system works w/o stapling, but is needlessly inefficient), and if stapling is an optimization, then it isn't really a requirements issue.

So, do you have any comments on the proposed MIDI requirements?

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

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