[gmpi] MIDI: Proposed Reqs (try #3)
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 14 Jul 2004 00:04:53 -0700
> 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.
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.
Use case: 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 (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 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.
* 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!
* 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.
* 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.
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
