[gmpi] Re: Reqs 3.8 Events - ramped events

[sorry this is a long reply, but its a complex subject]

On Sat, Jan 24, 2004 at 02:26:53 -0800, Chris Grigg wrote:
> >Just because we dont want to represetn these things as integers doesnt
> >mean that there is any loss of information, you can store the CC values as
> >a real and round it out to an int if/when it leaves the graph and becomes
> >serial MIDI again.
> 
> 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.

Yes, but only outside the GMPI graph. Notes will get rounded to the
nearest semitone -0 but thats aunavoidable - either GMPI notes are not
compatible with MIDI (which would be very bad) or you have to accept that
non-12TET notes will get repitched if you send them over serial MIDI.

If all you do inside the GMPI graph is things that MIDI can represent then
it will be 100% MIDI compatible.

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.
 
> > > 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?
> >
> >The conversion is lossless, so no.
> 
> Only at the data field level.  My point is also about the 
> message/destination semantics.  There's inherent destination 
> addressing in a protocol like MIDI, but with one level of 
> indirection. There is great value in allowing a plug-in to map, on 
> its own, without host intervention, a given incoming message to a 
> given internal parameter/function/etc. of its choice.

That should be doable using hints.
 
> > > - 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?
> >
> >Yes, or by a plugin. It doesnt really matter, the importnat things is that
> >it gets converted to a unified GMPI control value representation, and not
> >7/14bit int coded in 8bit serial.
> 
> A) You seem to be making an assumption that unification is more 
> important than legacy device support.  Am I interpreting you 
> correctly?

Not quite - legacy device support is probably most important, but if
legacy devbice support only happens at the sufference of pluigin
developers it will not happen, or will happen badly. If we can arrange it
so that plugin authors can support MIDI (and OSC for that matter) with
little or no extra effort then it /will/ 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 think it should be possible to implenment something as complex as say a
step sequencer, using only GMPI native controls and have it interoperate
with serial MIDI devices with no problems. [assuming you only want 12TET
ofcourse]

> B) MIDI has a couple basic aspects that are essentially independent, 
> and we don't necessarily have to take all of them in the way we 
> handle (or don't handle) MIDI.  There is a message format model, 
> which is where the 7-bit stuff comes in, however this is orthogonal 
> to the sender/receiver model (which enables message end-to-end 
> routing) and the addressing model (cables, channels, 
> notes/programs/controllers/sysEx).  The sender/receiver model and the 
> addressing model are IMHO valuable and should in some way be given 
> room to exist within GMPI.  Whereas I agree that the 7-bit packaging 
> is an irritation and could/should be transformed in some way at the 
> GMPI graph bounds without information loss... although as I say, 
> there are a lot of plug-in MIDI synths today, and users love them, 
> and I do think GMPI needs to make things easy for those plug authors 
> if it's going to succeed.

Agreed. But those are all things that GMPI has (or needs) equivalents of,
with the possible exception of channels, but channels can be mapped to
multiple controls and hints.
 
> 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.
 
> > > - In actual practice, how is the int/real conversion configured for
> > > scale & offfset etc. by the user?
> >
> >MIDI cant encode scale and offset, so it doesnt have to be.
> 
> Not sure you understood my question.  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.

> 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.
 
> >I dont understand the problem, the basic idea is that MIDI is coded up
> >into some sort of preparsed format for transmission around inside of the
> >GMPI graph and if/when it has to leave it can be turned back into 'real'
> >MIDI. There is no compatibility problem.
> 
> See above, I think there are a few more issues there than you are 
> accounting for.  There are a lot of devils and losses of flexibility 
> in 'preparsed'.

Yes and that is why you have the unparsed "blob" get-out clause :) You
preparse all the things that people are going to want to use often and
allow unparsed blobs for everything else. This is what the linux
alsa-sequencer routing system does and it works fine.
 
> >The portential problems with hadling 'raw' MIDI are:
> >
> >1) people have to write midi parsers. thats anoying and easy to get wrong.
> 
> Can you comment on the existing large number of MIDI plug-in synths? 
> Also MIDI event parsing isn't .that. hard.  Getting efficient DSP 
> code working and sounding right is, for most people, a lot harder.

Its hard enough that it is a frequent source of bugs:
http://www.google.com/search?q=midi+bug+vsti

But its just unnessary, why make people have MIDI parsing code when they
could just (in the 99% common case) just hint up thier controls and get
automatic MIDI (and OSC) support with no extra effort.
 
> >2) its not sufficiently expressive.
> 
> There are many many problems with MIDI.  Can you be more specific? 
> Also, note that MIDI receivers have a great deal of latitude in 
> mapping any possible control source to any existing parameter in the 
> plug-in.

Cant have overlapping notes in the same pitch, cant have non 12TET
(without additional contextual information), cant have controllers with more
than 14bits of dynamic range, cant have more than 16 channels...

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 dont want to have to deal with two
> >   different kinds of note on packets (for example), so I need one that is
> >   both MIDI compatible, and adeqately expressive for academic music.
> 
> From they way you frame this point, can I take it that if there were 
> a solution that allowed those who are interested in MIDI-controlled 
> plug-ins to do what they want to do, and it was implemented in such 
> as way that it didn't get in the way of the kind of plugs that you 
> want to write, then you wouldn't object?

Yes, but I think they ways we envision that happening are a bit different
:) I want my plugins to be compatible with MIDI (and OSC), wether or not I
have/want to handle MIDI (and OSC) explicitly.

I have no doubt that some plugins I will port to GMPI will need explicit
MIDI code (eg. anything that uses SYSEX to control external boxes), but
the common case of an instrument with a few parameters should not require
MIDI-specific code.
 
> >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.
 
> >I also want the control packet for to be OSC compatible (at least at a
> >basic level), and I'm definatly not handling 3 packet formats.
> 
> Maybe you and I both suffer from the "When the tool you know best is 
> a hammer, all problems tend to look like nails' problem... your 
> hammer is OSC, mine is MIDI.  I have to say, I wonder whether there 
> is broad support for OSC in GMPI.

I'm just using OSC as an example (I'm writing an OSC parsing library at
the moment so its in my head, but I have /far/ more MIDI hardware than OSC
software). 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.

OSC support is much easier as it comes from the natural valued, named
parameter world and plugin can generate/receive it natively (though GMPI
should standardise support for with a known mapping), but my point
is that MIDI should not be too much of a special case.
 
> One possible way to go -- yes yes, I expect everyone to shout 'no' -- 
> is to have a level of protocol indirection in the event message 

"no" :) I just dont see the point - for things GMPI can't/won't support
nativly you have blobs (which can do this fine AFAICT) and weher possible
ti makes sense to transform MIDI/OSC/whatever into GMPI native concepts
and structures.

> This way plugs could advertise which protocol(s) they send & respond 
> to, can ignore protocols they're not interested in, and hosts can 
> refuse to make inappropriate connections.  Existing MIDI-based plugs 
> could be migrated to GMPI more easily, protocol conversion plugs 
> could be written, etc.

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.

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

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

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

> >I think there are two seperate issues here
> >
> >A) lumps of (parsed) MIDI floating around the graph (notes, maybe CC's
> >   etc).
> >
> >B) MIDI CC's bound to plugin control ports.
> 
> Not 100% sure I agree with your analysis, what do you mean by 
> 'parsed'?  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.

Yes, parsed was the wrong word here, I meant GMPI native control
(including typed blobs).
 
> >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.
 
> 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.
 
> 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.

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

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

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