[gmpi] Re: a bit on MIDI (was ramped events)
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 24 Jan 2004 15:15:09 -0800
On Sat, Jan 24, 2004 at 02:23:17PM -0800, Chris Grigg wrote:
> Thanks, Tim.
No, thank you! I've been missing GMPI discussions. Sometimes it's fun to
banter about stuff, even if it doesn't really apply to the topic at hand.
:P
> >> representation of a MIDI controller value should be done via an
> >> integer.
> >
> >Agreed, but only up to a point.
>
> I should have added: As long as data integrity is preserved, and no
> un-convertable intermediate values are generated, either integer or
> real variables could be used to communicate MIDI controller values
> within a GMPI graph. Was that your reservation?
What I meant was that pure MIDI should only make it as far as an edge of the
GMPI graph before it is convereted to GMPI native stuff.
> >computer. A MIDI knob doesn't know or care whether it is actually
> >controlling an int, float, bool, or who knows what else.
>
> Well, often the user does, it's just that message interpretation
> depends completely on the receiver. When the receiver promises to
Right, again, that was exactly what I meant. The control surfaces are just
fine the way they are, if a bit limited by 7 bit resolution.
> boundary. Limiting the use of MIDI messages in GMPI to just the
> standardized meanings would kind of suck IMHO. MIDI was never meant
> to be limited in that way.
Oh, no, no such limit needs to exist. That would be bad bad bad.
> think we also have to take seriously the fact that MIDI parser
> writing has already been done at least hundreds of times in existing
And is a waste of memory and CPU, and is a waste of programmer time for new
plugins.
> plug-ins written to other formats, and that a large percentage of
Here is a real issue I had not thought of - If GMPI is radically different
on this front, then it makes life harder to write a plugin that is released
as GMPI and VST/AU/etc. On the other hand, I don't care. I want to
supplant VST.
> I think you're right, "MIDI learn" is properly a host
> feature/function, and the GMPI design should not IMHO do anything to
Exactly. Some hosts already do this, and it works REALLY well.
> there needs to be some runtime way for the expert user to override
> the default connections at the graph level, and also some way for
> renegade plug authors to override the standardized message
> interpretations at the plug level, at coding time. Otherwise one of
> MIDI's most redeeming qualities -- the flexibility of indirection --
> is lost.
Agreed. A host SHOULD allow you to remap incoming MIDI at will. The
automatic stuff is really just hints. The host can ignore it. A plug that
wants to receive CC#7 and treat it like a pan (as opposed to volume) should
need to do nothing more than hint that a control is CC compatible with CC#7.
How's THAT for simplicity. You just specify that hint, and the host should
automatically route CC#7 to your preferred knob.
> destination manually, and does not preclude an idiosyncratic plug-in
> from handling incoming MIDI-originated events in non-standard ways.
Absolutley. Receiving MIDI is about specifying which MIDI information you
want to receive. What you do with it is up to you. The host will
attempt to or offer to (or maybe not) automatically set you up for incoming
MIDI. I fyour hints are right, you'll get what the plugin expects. The
user can reconfig, if the host allows it.
> Ghost console does a goofy thing that I love: it responds to MIDI
> notes by unmuting (note on) and muting (note off) its channels (notes
> 0-31 are channels 1-32 main mutes, 32-63 are channels 1-32 'Mix B'
That's a great example! I was thinking of things like Ableton Live which
uses MIDI note on/off to trigger loops.
> otherwise. If GMPI always converted MIDI note indexes to pitch, or
> always forced certain source/dest connections, this kind of creative
> controller re-mapping could be prohibitively difficult to do in GMPI.
Yeah, pitch is a fun one, though certainly not impossible to handle.
> >We can make it Just Work in two ways. If the plugin uses well-known CCs,
> >you can use a hinted name. For example a control named 'VOLUME' might be
> >assumed to be the MIDI CC#7.
>
> Assumptions can be the root of a significant amount of
> non-functionality... so I would be a lot more comfortable with this
> if there were a mechanism for the plug author to optionally supply a
> specific MIDI CC number hint, as you expand on a bit below, to enable
> nonstandard stuff. I agree that if the plug author doesn't supply a
> hint for Volume, CC7 -> Volume is a reasonable default connection.
OK, I didn't really mean assume :) I would imagine there would be a flag
that said it was MIDI-compatible. In fact, I assume there would just be a
template that allow the coder to add a knob that is a MIDI-compatible knob
(float, [0-1.0] or [-1.0 to 1.0], hinted for a CC#, etc).
> Sure you could do it. This is related to what I was suggesting
> earlier with optionally stapling an aux 'MIDI In' pin to the side of
> each real-value pin, with a built-in conversion function supplied by
> the plug. You could have both a 7-bit aux pin and a 14-bit aux pin
I was about to say that it was analogous, but it's not quite. Assume a
Volume knob is a float [0.0, 1.0]. You may be happy with 7 bits of
precision during live performance, so you link 1 7-bit knob on your MIDI
controller to it via the host. Incoming MIDI is then turned into float by
f(x) = val/127.0
Howevere, *I* prefer more control, so I link TWO MIDI knobs to that same
volume control. For me, incoming MIDI is turned into float by the funtcion
f(x) = (val_1 + val_2)/254
Either way, all the plugin sees is incoming float values. The rest is
handled by the host.
----------------------------------------------------------------------
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:
