[gmpi] Re: Reqs 3.8 Events - ramped events
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 23 Jan 2004 14:07:04 -0800
Koen, Steve, Steve, and David --
a) Slow list lately.
b) I must have expressed myself badly on the following point, since
people are sounding like they're disagreeing with me while saying
things that I don't actually disagree with. Sorry for any murk, I
blame a NAMM headache when I was writing those posts. This will, I
hope, be clearer in explaining the problem I see and proposing some
possible ways to address it.
Koen said:
On Friday, January 16, 2004 7:26 PM [GMT+1=CET],
Chris Grigg <gmpi-public@xxxxxxxxxxxxxx> wrote:
Why? The things being represented (value of a MIDI controller) are
truly, madly, deeply, not to mention naturally integers.
and
MIDI control events is one layer, DSP math parameters is another
layer. Let the plug map MIDI controllers to a real-typed control if
it wants, but the nature of MIDI controller values per se -is-
integers. (OK, bool in some cases.)
I think I should raise my voice saying that the things that are represented
by MIDI controllers are usally NOT truly, madly, deeply and (certainly not)
naturally integer.
I agree with the text of your statement completely, however it also
seems that my point has been completely missed. I did not say that
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. Obviously faithful representation of something that a MIDI
controller controls in many cases requires a real-typed value, but
that doesn't necessarily mean that GMPI only needs to route the
latter and not the former.
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. Of course at some point the integers need to be
scaled & offset (and maybe warped via some curve to an appropriate
shape) to be converted into the low-level audio DSP parameters that
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.
Whereas you guys seem to be proposing that we turn all this on its
head, so that what the host routes is only the DSP-level values and
not control-surface-level values.
It seems to me that this has some real problems for practical studios
and music production. For example:
- 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
GMPI host when it accepts the control input from the peripheral,
before sending into the plug graph? By a driver for the peripheral
before it goes to the GMPI host?
- In actual practice, how is the int/real conversion configured for
scale & offfset etc. by the user?
- If the existing controllers .do. need to go to the bottom of a
lake, them won't GMPI depend for its success on the arrival in the
retail market of some hypothetical new future generation of control
surfaces that send slider positions as 64-bit floats or something?
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
like scalewise transpose or automatic scalewise harmonization, or
ordinary note synthesis, into impractically complex
analyze/resynthesize operations. I can see that the motivation for
these ideas is pure, but the ideas themselves strike me as both 1)
impractical and 2) barriers to GMPI acceptance, insofar as they would
a) tremendously complicate the porting of all the very popular
existing MIDI synth plug-ins to GMPI, and b) obsolete the end-user's
investment in MIDI controller gear.
I would propose this kind of approach instead: GMPI hosts should be
able to route both control-surface-level integer-based control
signals and parameter-level real-based control signals equally well,
and without degrading the native signal format for either. (MIDI
being just one case of a control-surface-level integer-based signal
format.)
Some are, but most are not: amount of expression, volume,
effects level, balance, pan position, etc... are NOT integer entities by
nature. Hence, I would also not want to model them as integers.
I will agree that even real values represented in a computer are discrete,
but please let's not model real values by integers from the start...
All that's fine and true, but also not responsive to my statement
that the value of a MIDI controller is an integer. A GMPI graph
shouldn't be modelling any parameter class (volume, pitch, etc.) in
any particular way at all, as doing so places some set of arbitrary
global limitations on all GMPI plug-ins' musical possibilities. Hosts
should IMHO be totally signal-neutral, enabling plugs to do whatever
they want, instead of dictating to them, as far as possible. So your
plug can do its own modelling it any way you like, but your
preferences here don't necessarily need to be turned into GMPI-wide
rules -- for example, a plug developer whose only interest in GMPI is
how easy it will be to port his MIDI analog modelling synth to GMPI
would likely see the situation differently than you do.
If
people want to use these values in a MIDI protocol communication, they will
have to quantize them.
That's true for output. But if GMPI plug authors want to accept
control .input. from currently existing control surfaces -- which
are, overwhelmingly, senders of MIDI controller messages -- then
wouldn't you say that they'll have to accept quantized control MIDI
inputs? And that to do that they'll have to usefully cope with some
of MIDI's limitations? I mean, what control surfaces that you know
of are capable of sending real-valued control change messages?
Again, if control inputs are typed and named, why does GMPI need to
dictate what model all GMPI plugs will use? Let some plugs use
"Pitch-Hz" real inputs and other plugs use "Pitch-MIDINoteNumber" int
inputs.
But only then, not within GMPI.
Unless I'm mistaken, that's for the group to decide later, when we
get to setting requirements for how MIDI will/won't be handled... no?
Though I have to say, some of the anti-MIDI sentiment here -- not
naming names -- does strike me as kind of
religious/ideological/ivory-tower/anti-user.
Just my opinion though...
And I completely respect it. Just hope you guys can see the flip side too.
Possible solution: Maybe we could add a rule that all real-valued
control input pins could also optionally provide some sort of
built-in aux input pin that accepts integer-stepped control inputs
(like MIDI controllers etc.), which comes with a converter function
for automatically scaling & smoothing & converting & feeding the real
pin? So you plug a real source into a control input and it goes in
directly, but if you plug (example only) a MIDI controller source
into that same control input, the plug is able to easily handle its
own CC-to-real-param conversion? Then we get both worlds side by
side.
-- 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:
