[gmpi] Re: Reqs 3.8 Events - ramped events/MIDI

In deference to Ron's hold-off request, my last replies on MIDI for now. I think it's converging. Replies to Steve, Koen, & Tim all included below.

-- Chris G


I. Replies to Steve

Steve said: 
I think we have the same goals (broad and extensive MIDI support) but see
different ways of achieving that.

Yes, after reading your last msgs I'm sure you're right.


Chris Grigg wrote:
 > But is this really viable across the board?  An in-graph note index

 of 40.5 converting to a MIDI wire note of 40 or 41?  An in-graph
 sustain pedal value of 0.5 converting to a MIDI wire CC value of 0 or
> 1? This is a source of error.

...
Given some extra information it would be possible for a host to convert
outging float accurate pitch information to note on + pitchbend like
guitar midi controllers do.

Not without knowing what scale the external device is using, which would require either GUI support or 2-way MIDI communication.. not gonna happen.


The trick is to support MIDI unambigiously and losslessly without it
impinging on the design or complexity of plugins (that dont need to care
about low-level MIDI/OSC things). I think thats possible.

I hope you're right, and I'm glad you think that.


> C) If GMPI forces conversion of integer control surface values into 
 real values to occur at the GMPI graph bounds (by the host), then it
 eliminates the possibility of allowing more than one plug destination
 to respond to the integer messages in different ways.  Compared with
 existing plug formats, this is a loss of functionality.

I dont think thats right:

      -----------------------------
      | GMPI Graph                |
      |                           |
MIDI  | control  .----------.     |
------+----------| Plugin A |     |
      |\         '----------'     |
      | \       .----------.      |
      |  '------| Plugin B |      |
      |         '----------'      |
      -----------------------------

The MIDI CC can be mapped in different ways at the boundary to meet the
needs of A and B.

How, if the needs of A & B are different? You'd need separate MIDI-A & MIDI-B lines, separately scaled. Also, doesn't work for notes: If you convert to some freq-based or scale-based system at the boundary, you force all the synths inside GMPI to work in the same intonaton system... what fun is that?


 > If I understand correctly, all
 > y'all propose GMPI graphs contain & route only 'natural value'
parameters, i.e. frequency in hz, maybe filter Q as a coefficient,

pitch in octaves/semitones, rather than freq in Hz, but yes.

Octaves/semitones makes its own assumptions (all octaves have same scale, plus assuming that there are even octaves at all) and can be encoded losslessly as simple note number index, as MIDI already does... so (except for the 128-range limitation) MIDI's approach is actually more flexible in this regard.


> level in dB, etc. Whereas MIDI speaks in terms of integer control 
 values with in many cases no predefined mapping from control value to
 represented real value.  So my question is: what is your proposal for
 where and how such conversions on incoming events from MIDI
 controllers (incl. control surfaces) are performed?


They are performaed individually for each control input that takes data
from external MIDI sources.

Still, someone needs to makes sure that the range & maybe curve are scaled appropriately. Forcing this to be done manually for every connection would be bad, was my point.


These are all limitations that we have to respect when exporting control
data from the GMPI graph to serial MIDI land, but we shouldn't feel bound
by them internally and we shouldn't make people (who want to support MIDI)
have two seperate event handlers inside thier plugin.

I agree, they should be able to support just the MIDI i/f if that's what they want to do.


> >obviously if I use high resolution data values inside of the GMPI graph,
>when it get exported to serial MIDI that extra res will be lost, but at 
 > >least I had the oportunity to use it in the first place.
 >

 But if the external device unexpectedly responds with a different
 behavior than plugs in the graph do, then the extra res can also be
 seen as (and many users would experience GMPI as) a generator of
 wrongness.

I doubt it, people are used to MIDI CC's being a bit steppy.

Not as OK for notes. If you Y a sequencer track to both a GMPI synth plug and a MIDI out, the synths should play in unison (all else being equal).


My concern is that if you require explicit support for MIDI,
you also require explicit support for OSC, or whatever future control
protocol comes along.

I question whether there is any single perfect protocol. Every protocol limits the music than can be made in some way. We can make choices among alternatives, and make some improvements, but something better and more expressive will always come along later. And we should not accept something that does less than the other plug APIs. I would think more in terms of extending, and less in terms of replacing.


OSC support is much easier as it comes from the natural valued, named
parameter world and plugin can generate/receive it natively...

Easier if you're writing certain styles of new stuff from scratch / not easier if you're trying to port an existing MIDI synth plug-in quickly.


Porting a plugin with an explcit MIDI parser to a system when MIDI is
preparsed is easy - I've done it - you just remove the byte parser.

Again, with respect, I think that this is not necessarily in all cases so easy. Many MIDI synths are built from the ground up on MIDI architecture assumptions, and we want them over here in the GMPI sandbox.


> Because it's completely new and nothing that currently exists will be 
 able to work within it in a reasonable timeframe?  I think it's not
 enough to get a working system, we need a working system with a
 reasonably efficient entry path for existing plugs in other formats.
 (This is a requirement we already agreed on, isn't it?)


MIDI parsing is not new (every VSTi does it internally and there are
nmumerous systems that do it in the engine).

No no, I'm saying flatly outlawing MIDI parsing (by flatly precluding MIDI routing at the graph level and allowing only 'conceptual' values) would be the new, bad thing.


We also probably should handle MIDI at the byte level so as not to rule
out systems like DMIDI
http://standards.ieee.org/announcements/p1639app.html

I like RTP MIDI a little better, but agree we can't do away with MIDI byte access without essentially killing GMPI in the cradle, viability-wise.


> Couldn't agree more, wish we had a time machine to go back and fix 
 MIDI in the cradle.  But it's a reality and we have to deal with it.
 One consolation: when you look closely at MIDI in GMPI, at least
 there are some things we get a chance to improve.


I think there was very little worng with MIDI (possibly it should have
been bidirectional), but it was limited to some extent by the technology
of the time.

But but but... you also gave a nice long list of the problems with MIDI...?


> >A needs good, lossless representation of the MIDI data, it doesnt need any
>particular scaling hints or whatever, as MIDI doesnt have them.

 This is only true if plugs are free to receive notes as indexes and
 not frequencies.  Are you saying you're OK with notes as indexes?


No, but GMPI can seperate pitch from index internally and only remap them
externally. Again this would be lossy when you went to external, serial
MIDI systems, but DMIDI and MIDI-over-OSC will handle it well.

I thought P-1639 (DMIDI's new name) was MIDI wire equivalent.


> If you let a plug have a MIDI In control port then all the individual 
 controller routing for that plug is handled automatically within the
 plug, with no host load and no host GUI needs to be written by the
 host author nor played with by the user.  Lots and lots of popular
 plugs already work this way.


Yes, but IMHO hosts that also allow you to bind controls at the host level
are very convienient: less mucking about with virtual midi connections and
a consistent binding UI.

These ways are not mutually exclusive. Connect a virtual MIDI patch cord, or click a knob and wiggle a MIDI fader, most hosts support both.


> Maybe we can find a way for you to get what you want without also
putting walls up for the authors of such existing plugs. 

I think so. I am 100% against blocking any existing functionality, but I'm
also 100% against requireing people to have to add expitict support in
every plugin for what is a very widly used, and easy to use protocol.

That's fine, and let's distinguish between 'require' and 'allow'. I just want to 'allow' a MIDI plug-in writer who wants it to get an unmolested MIDI feed without having to conform to GMPI's vanilla abstraction of what 'proper MIDI' is supposed to mean.


- Steve, "make the 95% common case easy and the 5% hard case possible"

You don't really mean that, since then bang goes all the computer music research driven requirements... 8-)


Steve said: 
Tim Hockin wrote:
 > Chris Grigg said:
 > > 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.

Disagree, MIDI is complex and we probably dont want to ecapsulate every
variation on it (eg. all the forms of SYSEX), so just let people blash out
known-typed blobs that will be sent out at the edge of the graph as midi
bytes and used as blobs internally.

Exactly right IMHO. Next logical step: If MIDI can be routed as blob msg contents, then what's the downside to having -two- kinds of blob msg contents, and calling the second one MIDI?


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

And a big source of bugs.

Sure, but I think the correct response to that problem would be to start a Sourceforge project for a nice tight reliable MIDI parser (or maybe a family of MIDi parsers, since different applications have radically different needs), not to outlaw MIDI parsing inside GMPI. If you're going to allow non-standard uses of MIDI, the correct place for a MIDI parser -is- in the plug-in. If you're going to prevent non-standard uses of MIDI then the correct place for the MIDI parser .may. be at the edge of the GMPI graph.. but then GMPI becomes less capable/convenient than VST etc., so what's the point?


II. Replies to Koen

Koen said: 
Chris Grigg said:
 >...what is your proposal for
 > where and how such conversions on incoming events from MIDI
controllers (incl. control surfaces) are performed? 

I would think the best place would be in the receiver (probably the plugin)
that knows how to interpret/convert the values, but possibly with the help
of the host in the form of standard MIDI messages to real value conversion
routines.

Good direction, but standard conversions will not know what value range the sender is sending, nor what value range the receiver needs to see, nor what curve the receiver needs to see. Manually configuring this for every connection is prohibitively messy for the user. Putting the conversion in the hands of the receiver makes IMHO more sense.

Maybe these ideas can be combined: For each control input, the plug author provides some metadata that can be fed with the CC value to a host conversion function to turn MIDI in to the needed real input... gmpiRealParm gmpiHost::convertMidiCcToReal( MidiCcVal, ccMin, ccMax, realMin, realMax, curveID ) where ccMin, ccMax, realMin, realMax, and curveID are provided statically by the plug. So the host does the conversion, but with guidance from the plug, and no other MIDI-pseudo-pins are needed?


Well, at least one of the bigger players that apparently saw the usefulness
of OSC is Native Instruments: they are using OSC in Reaktor.

Cool, how do they deal with MIDI evt conversion?


It's not that we don't want support
for MIDI, but just not as the base within the GMPI graph, so that the limits
are not baked in from the start.

Yes yes, then we agree: Support easy & flexible interoperability with external MIDI devices, and make GMPI porting of existing MIDI-driven plug-ins easy, but don't encumber the GMPI native event i/f or models with any of MIDI's hard limits, and don't encumber the MIDI implementation with any hard preconceptions of the meanings of MIDI messages. Can we all agree to this goal statement?


 > If sysEx communication between external devices and plugs
 > is going to be supported (needed for some control surfaces), then

 you'd need actual MIDI byte sequences to be able to move around
 inside GMPI graphs.


I think one of the GMPI parameter types was some kind of opaque blob of
bytes, so if you need to move sysEx things in the graph, that will not be
impossible.

Has to be not just impossible, but relatively easy.


Koen said to Tim: 
Personally, I would think converting from internal "conceptual messages"
into "MIDI bytes" is only done in the wrapper for the plugin format it's
being used in. So, if the code is written that way, the MIDI handling is not
done directly and can be exchanged for something else, right?

The problem is that the meaning of MIDI messages depends entirely on the receiver, so if GMPI assumes 'standard' meanings for MIDI messages, and uses those assumptions to auto-convert to 'conceptual' values, it's going to break a lot of existing HW & SW products and preclude a lot of inventive uses of MIDI that other plug formats would allow.


Koen said: 
Tim said:
 > ...I don't want to know what CC# each knob
 > in SynthX is.  I don't want to figure out MIDI learn on each Synth I

 buy.  I want to right-click->link-to-MIDI and then waggle a knob.  On
 EVERYTHING. The same way.  I want to be able to write plugins that
 can be controlled by MIDI without writing a MIDI parser and building
 it into each plugin.

I fully agree with this. This *is* probably as user-friendly as it can get.

This is just a question of host functionality, and could be done equally well if it were MIDI that was being routed to the plug.


III. replies to Tim

Tim said:
SysEx, yeah. I meant just unnamed CC numbers should still work.

Undefined MIDI CC's have no predefined semantic meaning, so no auto-conversion to 'conceptual' values is possible... therefore. if you want this, then we have to provide a routing mechanism for non-conceptual values in GMPI.

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

Other related posts: