[gmpi] Re: Reqs 3.8 Events - ramped events

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 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.

> 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?

> - 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.

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.

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.  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, butthe
host can still do the magic to make it work.

> 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.


----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: