I think this needs to be clarified a bit. * There must be only one semantic for each data element. If such semantic exists in MIDI, it must be represented in GMPI _as_ MIDI. However, GMPI may optionally represent such data elements at higher precision or out of MIDI range, or with note ID. In other words, I don't think the idea of GMPI "parallel" should mean that there are 2 opcodes, 1 MIDI and 1 GMPI, for note pitch, and so on. Original Message: ----------------- From: Tim Hockin thockin@xxxxxxxxxx Date: Wed, 23 Jun 2004 22:54:56 -0700 To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] Re: MIDI: Common event coding 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 -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . ---------------------------------------------------------------------- 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