[gmpi] Re: Reqs 3.8 Events - ramped events
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 24 Jan 2004 14:23:17 -0800
Thanks, Tim.
On Fri, Jan 23, 2004 at 02:07:04PM -0800, Chris Grigg wrote:
the things that MIDI controllers represent are integers. What I said
was that the value of a MIDI controller is an integer; faithful
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?
> I think a basic semantic error is being made here by glossing over
that distinction. Basically all existing control surfaces that I
know of and their existing comm protocols (like MIDI) encode slider
positions, velocities, etc. as integers. I didn't invent that, it's
just the way it is.
Right. And despite the fact that MIDI is mostly 7-bit values, it works
pretty well for shuttling destination-independant data from hardware to a
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
behave according to one of the standardized MIDI device specs (GM,
GM2, DLS, etc.) or industry-consensus common practices the user knows
what to expect, but the receiving device can always be more
interesting than that. It's only the whole end-to-end chain that
determines the meaning of the sent message, so we have to decide how
to handle those semantics as we make MIDI lines cross the GMPI graph
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.
> the control integers drive, but under all current pro plug-in systems
this conversion happens at the plug-in stage -- so hosts essentially
route incoming MIDI streams from external devices directly to
plug-ins, they don't route exclusively parameter value streams.
And I think we can do better than that. Why have a MIDI parser in every
plugin? Why should a user have to figure out the CC values for plugins?
Why implement MIDI learn in so many plugins?
Improvement is great, and an important goal of the GMPI project. I
think we also have to take seriously the fact that MIDI parser
writing has already been done at least hundreds of times in existing
plug-ins written to other formats, and that a large percentage of
GMPI users, especially the more serious ones, are already familiar
with MIDI, so reading a MIDI implementation chart or opt-clicking a
slider and then wiggling a MIDI fader are second nature and not a
great new burden. This amounts to both a functionality expectation
from the user and developer bases, and an opportunity to increase the
likelihood of success for GMPI.
> - Do you propose to toss all existing control surfaces into a lake?
- If not, where exactly in the architecture or graph do you propose
the control-values-to-parameter-values conversions be done? By the
In the host. The host knows, or can be taught, the mapping between incoming
CC numbers and destination controls. The user can either explicitly teach
the host (map CC #X to control A), the host can implement it's own MIDI
learn that is cross-plugin, or plugins can provide hints to the host.
If you let the host implement it's own MIDI learn, you can do all sorts of
neat tricks. If you want 14 bits of range, you can tell the host to use two
7-bit CCs added together. If you want 21 bits... etc. It puts MIDI control
firmly in the hands of the user/host and not in the plugin. This can
provide a much more consistent experience.
I think you're right, "MIDI learn" is properly a host
feature/function, and the GMPI design should not IMHO do anything to
preclude this. (Though training the int-real conversion for a lot of
destinations parameters could, I think, be tricky and a big potential
drag.) And having a default mechanism that allows external MIDI
sources to auto-connect to destinations in the GMPI graph is good
too. But stopping there wouldn't be a complete solution. I think
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.
Many CC numbers are well known. That is, they have a meaning that can be
assumed about them. If your plugin has a 'volume' knob, and the host
receives a CC#7 it makes sense to make that 'just work' doesn't it? It
might, depending on your host.
This is good, but if and only if the GMPI architecture does not
preclude the user from deciding to remap a controller's ordinary
destination manually, and does not preclude an idiosyncratic plug-in
from handling incoming MIDI-originated events in non-standard ways.
We need to be careful about that. For one example, my Soundcraft
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'
mutes) and this allows convenient creation of all kinds of
MIDI-driven audio collage compositions that wouldn't be as possible
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.
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.
We can go further by standardizing these sorts
of controls. If the host knows that a control named 'VOLUME' is always a
float in the range [0.0, 1.0], it can transparently map incoming MIDI CC#7
to this control, while allowing GMPI native control at the same time.
The second way is to provide a CC-compatibility hint on each control. This
is less elegant, since you can't know the range and type a priori, but the
host can still do the magic to make it work.
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
where useful. And input range (MIDI CC) & destination range (plug's
real value) are both known to the plug at authoring time, so what's
unknown? Maybe I still like that better, leaving control of the
conversions in the plug author's hands -- say a mixer plug author
likes his 0 dB at CC value 100, and a mute plug author likes his 0 dB
at CC value 127. Or at least allowing the plug author to override
the host's default MIDI->real conversion where necessary/desired.
It's a little messy, but if you're not doing MIDI you don't need to
do it in your plug. You could do something similar for OSC
transcoding, maybe.
> You can see where this path leads. This is a lot like the earlier
proposal that note pitch be described only in Hz and never by scale
index (note number), which would turn ordinarily dead-simple stuff
I see your concerns. I *think* that a model like above can retain full
interoperability with MIDI, without succumbing to it's limits. All your
MIDI gear should Just Work.
Gotta think about your design a little more, but I do like the goal
as you stated it.
-- Chris G.
----------------------------------------------------------------------
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:
