[gmpi] Re: 3.15 MIDI

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 16 Jun 2004 15:41:14 -0700

1. OK, in this model how would the following be handled?:

- Sys ex
- MIDI out from plugs
- GMPI/MIDI transcoding side effects including:
        > Message execution time shifts
        > Running Status handling
        > (N)RPN parameter number tracking

2. On that last category,the more I think about it, the more it seems impossible, or at least it that it would be somewhat to very complicated, to have one GMPI message per MIDI message without losing MIDI stream byte-exactness.

Consider running status, for example in the context of an ordinary 7-bit controller message. MIDI device sends a full 2-byte status+data message, waits a minute, then sends another controller message but this time it's a 1-byte message, relying on running status to imply/repeat/insert the previous status byte. The host turns the first MIDI msg into a GMPI set-parameter message, the plug converts it back to MIDI, and sees a 2-byte msg; so far, so good. Then the plug gets a second GMPI message corresponding to the 2nd MIDI message, converts it back to MIDI... but now you've got another 2-byte message instead of a 1-byte message. MIDI received at the plug not exact with MIDI received at the host.

-- Chris G.

This is the best suggestion yet Michael.

How to support MIDI without breaking GMPI.

No MIDI in the graph...BUT...provide a GMPI to MIDI routine  (we have to
write one anyhow, for the host).
  Any plugin that wants MIDI uses this routine to convert the incoming GMPI
events back into MIDI.

The requirements will state that this conversion must be bit-perfect.  i.e.
MIDI > GMPI > MIDI is loss-less.

Even better than Tim's idea (sorry Tim!)

Also better than Ron's idea of wrapping GMPI in SysEx.

Jeff


----- Original Message -----
From: <gogins@xxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Thursday, June 17, 2004 12:29 AM
Subject: [gmpi] Re: 3.15 MIDI


I agree with Martijn and with you that some plugins will need to receive
control data, modify it, and send it back to the host; or that some plugins
will be generating control data or even entire scores. I've been mentioning
such requirements in my use cases all along.

That's the requirement. It's not a requirement that it be done IN MIDI
FORMAT.

If the mapping from MIDI to GMPI is adequate, all control data processing
and generation by plugins can be done perfectly well (better, if we do our
jobs) in native GMPI.

Again, as I pointed out earlier, if the GMPI to MIDI translation is
adequate, plugins that so desire may translate GMPI back to MIDI internally.

I see no requirement for the GMPI protocol to send MIDI formatted data to
plugins.




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



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

  1. Home
  2. gmpi
  3. Archive
  4. 06-2004