Let's figure out what we want to be able to do before we jump to
architectural conclusions. Here's an attempt to frame the (N)MiG
question from a goals perspective, instead of a nuts-and bolts tack,
please everyone jump in and edit. In particular, what does undo mean
for the kinds of things we typically use MIDI to control.
-- Chris G.
(proposed) GOALS FOR MIDI / GMPI INTEROPERABILITY
1 - MIDI STREAM PROCESSORS - Some plug classes want to modify a raw
MIDI stream, so raw MIDI with good fidelity must somehow be available
to those plugs. Because the semantics of a wild MIDI stream depend
wholly upon the receiver and are therefore not available to the host,
there is no possibility (and therefore no need to attempt) to provide
host automation control or undo capability for this kind of port, nor
to transcode the MIDI to/from OSC-style-address GMPI messages. These
plugs will also need MIDI Out ports. Is there any reason to disallow
chaining this kind of plug within a GMPI graph? Is there any reason
to disallow this kind of plug from having GMPI parameter outputs
(which don't need to be managed like inputs do)?
2 - MIDI CLICK-AND-WIGGLE - All plugs must OPTIONALLY be able to
allow/disallow live MIDI input control of each parameter via plug
custom GUI or host auto-built UI (ala "click, then wiggle"). I'm
guessing it's -probably- OK to limit this functionality to the
following (easily transcodable into GMPI messages, if that's what the
design team decides is needed) MIDI messages (but would like to get
input from control surface experts): 7-bit CC, 14-bit CC, RPN, NRPN,
NoteOn, NoteOff, Pitchbend (maybe channel and poly aftertouch, and
program change too). In a sequencer environment, MIDI gestures
performed this way must be recordable. Is there a need for this
style of input to be undoable? I'm not sure there is, partially
because I'm not sure what 'undo' means for some operations -- what do
host writers think?
3 - MIDI PERFORMANCE INPUT / NEW PLUGS - All synthesizer / sampler /
vocoder / etc. plugs needing scale-based performance input must be
driveable from live MIDI input (with out click-and-wiggle). Plug
must provide host with a MIDI-Msg-to-GMPI-parameter map. Probably OK
to limit this functionality to the following (easily transcodable if
necessary) MIDI messages: 7-bit CC, 14-bit CC, RPN, NRPN, NoteOn,
NoteOff, Pitchbend, Channel and Poly Aftertouch, Program Change. In
a sequencer environment, MIDI gestures performed this way must be
recordable. Again, is undo needed or meaningful here, since, unlike,
say, many audio DSP plugs, a synth plug's state is much more complex
(notes in release phase, envelope position, sample index per
oscillator, etc.) than a parameter snapshot?
4- MIDI PERFORMANCE INPUT / OLD PLUGS - For easier GMPI migration of
of existing plugs with designs tightly tied to MIDI, a modified MIDI
-> GMPI -> MIDI approach is recommended. The host converts incoming
MIDI to pure GMPI as per (3), and the plug author is responsible for
transcoding back to MIDI, internal to the plug, using a GMPI-provided
library. This has the downside of limiting the receivable MIDI
message set as per (3), which would in some cases block some unusual
functionality of some existing plugs, but the upside of allowing for
full host management of parameters (if that is indeed meaningful).
This can be easily done via a generic 'GMPI->MIDI shell' (or
GMPI->VST2, etc.).
5 - MIDI OUT - Composers may sometimes want to echo a plug's final
pitches/notes, parameter values, etc. to a MIDI device (Kyma follows
GMPI plug, etc.). Plugs OPTIONALLY supporting this functionality
will need MIDI Out ports. Integer key number truncation/rounding may
not always be acceptable; there should be investigation into the
OPTIONAL use of MIDI pitchbend messages (both 3-byte msg 0xEn and
Pitch Band Depth) for pitches between keys. A GMPI-provided library
should be OPTIONALLY available to promote consistent
GMPI-parameter-to-MIDI transcoding.
..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: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
