[gmpi] Re: 3.15 MIDI

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 15 Jun 2004 17:55:01 -0600



Martijn Sipkema wrote:

And I still haven't seen a good reason for only having a single control
protocol...


Let me try to give you a good reason. Lets say I am a synthesizer plugin, one sine wave oscillator, which takes a note on of a specific pitch. So lets say the host can pass GMPI events and MIDI mixed together.
For GMPI events, the note on has a frequency attached which tells me what frequency to generate. For the MIDI, I get a note number, which I need to translate into a frequency.
So how do I translate note numbers into frequency? Well, I use a look up table. Uh-oh, that's the same way that the host translates note numbers into GMPI events with frequency. Presto, either there are two table which the user has to set independently, or the plugin and host have to share a translation table. And this is a really simple situation.


Actually I don't that is a valid reason. The table actually might just as
well belong to a patch and thus one could argue that it should be on
the plugin side. Also, though it should probably be possible it is unlikely
that one would use both MIDI and GMPI parameters to control a
synthesizers (note on/off) at the same time and one would probably
only use a protocol other than MIDI if MIDI would not suffice. And
what is the problem with the conversion being done in two places?
The tables don't have to be shared. In the case of GMPI parameters
only, will the host ask the plugin for the note to pitch converesion
table that belongs to a patch and update it on patch changes?

I don't see how it is better for the user to need to set up a table for each synthesizer to handle MIDI->frequency translation, as opposed to doing it once in the host.
So let me try another tack. The GMPI event protocol will be a superset of MIDI. Every MIDI message will be able to be passed using a GMPI event. In the case of SysEx, it will be wrapped, not translated. So NOTHING IS LOST!
But because GMPI events are a superset of MIDI events, there are other possible messages besides the types represented using MIDI, and even the MIDI ones have added benefits like timestamps.
All of this is managed by the host. MIDI comes into the host. The host applies whatever mapping the user requests, and sends GMPI events to the plugin. This way, it is also the host's responsibility when OSC messages come in - they are turned into GMPI events.
The reverse happens for output. A plugin outputs GMPI events, which are mapped to MIDI by the host.


Where is the problem here? Why is there all of this yelling? Everyone who needs only MIDI is completely satisfied. Everyone who needs more than MIDI is satisfied to the extent to which GMPI events meet their needs. Before joining the corporate music community, I worked as a composer and programmer in the experimental music community, and I frequently needed more than MIDI to do the things that I wanted. So no one is saying throw out MIDI. We are simply saying that there are legitimate musical needs for which MIDI is ill-suited, so lets use protocol that is the intersection of MIDI and those needs.

--
Mike Berry
Adobe Systems


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