[gmpi] Re: 3.15 MIDI (goals)
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 18 Jun 2004 11:08:14 +0100
On Thu, Jun 17, 2004 at 02:22:06 -0700, Chris Grigg wrote:
> (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)?
Chaining MIDI -> MIDI seems reasonable, and allowing GMPI outputs seems
reasonable. I would like the equivalent for OSC (and ...) too, but I'l let
it drop if noone else is interested.
> 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?
Yes, there is a need for it to be undoable - the user wont see any reason
why wiggling a slider on a MIDI box is different to moving it with a
mouse. Its no harder to undo either, as the MIDI->GMPI mapping happens
inside the host, just like the mouse->GMPI mapping.
I like allowing the GUI to send a "bind this control to next
MIDI/OSC/whatever event", and "unbind this control" too. that way it gets
to control how, when and if the binding happens. Possibly the host should
provide a list of things the control can be bound to, so the UI can return
a (subset) list of the things it wants to be interested in (eg. you might
not want your pitch control to be bound to anything but pitch-bend or
[N]RPN for resolution reasons).
> 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?
Again, yes, undo is both meaingfull and needed. Not all hosts have to
provide it, but theresno reason to prevent them.
> 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.).
This seems reasonable.
> 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.
I think the trascoding library is a seperate issue and I'm not sure it
makes sense for GMPI to provide it. I'm guessing these MIDI outs wouldn't
(normally) be routed to other plugins? The idea is to send them outside
the GMPI graph, right?
- Steve
----------------------------------------------------------------------
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:
