[gmpi] Re: Drilling down into MIDI->GMPI conversion
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 22 Jun 2004 10:35:32 -0700
Good, Ron. Let's really see if there are insurmountable holes. Since no
one seems to be concerned with answering my queries for more information
on why MiG *is* needed, let's see if we can shoot down NMiG.
On Tue, Jun 22, 2004 at 09:49:17AM -0400, Ron Kuper wrote:
> [1] Musicians can and will continue to record and perform music using
> MIDI gear. This means that any host application which allows the user
> to record music will support MIDI input. AFAIK they all do today.
> This means that every host app which supports GMPI -- which I hope
> means every host app! -- will need to perform MIDI->GMPI translation,
> if it wants to host GMPI soft synths.
SDK
> [1a] MIDI->GMPI conversion puts a new burden on a host app that wants
> to support GMPI music plugins. That could slow adoption.
SDK
> [2] MIDI note-on messages are atomic in the sense they specify pitch
> and "velocity" in one go. It's not clear to me how you can translate
> to this atomic event into a GMPI event while retaining atomicity, but
> maybe I missed that one.
Hasn't been discussed, but can be solved (for example, voice IDs can link
events, or timestamps can indicate atomicity).
> [3] There are 128 CC messages, 16k RPNs and 16k NRPNs in MIDI. If
> MIDI->GMPI translation is to be done in a "shallow" way by simply
> converting bytes to floats, then a converter component needs to
> specify ~32k parameters as meta data. And plugins which respond to
> MIDI need to, too.
This is too shallow. MIDI->GMPI should use the natural parameters, not
*just* float. You only need to specify 32k parameters in the pathological
case of handling every RPN and NRPN and CC ever allowed. Are you telling
me you have such a beast? :) You expose parameters for things you want.
The rest get dropped by the host.
> [3a] Example: I want to write a plugin that acts as a MIDI (music)
> event filter. The user gets to choose which MIDI messages to pass and
> which to allow through. This plugin necessarily needs to expose 32k
> GMPI parameters?
You simply define the parameters that you want to handle. The rest never
even get as far as your plugin.
> [4] MIDI synths have fairly standardized controls like pitch bend,
> modulation and aftertouch. Connect any two hardware synths together,
> wiggle the pitch bend on synth A, and synth B responds predictably.
> Whatever GMPI's musical protocol is, all of these kinds of gestures --
> each of which has a unique MIDI CC# -- must map to a unique GMPI
> controller. Otherwise wiggling the pitch bend on my keyboard
> controller won't won't cause a pitch bend on my soft synth.
There should exist a well-known mapping between well-known MIDI CCs and
GMPI parameters. For example, if you have a hint that says "this
parameter expects the pitch-bend CC" then the host makes that all just
work.
> [4a] (Hearkens back to [1].) MIDI is the de facto language for
> capturing music performances today, and it's not likely to change
> soon. A MIDI message like "aftertouch" carries nuance and this must
> be retained across any translation. A keyboard controller connected
> to a hardware sound module should yield the same sound as a controller
> connected to GMPI host running the sound module as a plugin.
No problem. Map aftertouch to a parameter. If your synth doesn't handle
after-touch, it doesn't need to have that parameter. Ditto velocity.
Ditto pitch.
> ([3] & [4] suggest to me that for every *single* MIDI CC, RPN and
> NRPN, there must be a similarly named GMPI controller with the same
> semantics. If not, then you couldn't write a filter like in [3a], and
> you couldn't play a soft synth through a keyboard controller with the
> same level of interoperability as hardware.)
There is a smallish set of well-known CCs. Every other CC and *RPN can be
mapped to any parameter your plugin desires. If you want to map CC #123
to your comb-filter feedback level, that's fine. Thmain difference
between this and plain MIDI is that you are declaring this mapping,
instead of relying on a MIDI-map in the manual.
> [5] SysX needs to be it's own special blob type. A GMPI plugin can't
> say "my pin supports blob params" if it means "my pin supports SysX
> params." SysX is part of the gestural control I'm talking about in
> [4], so a GMPI plugin needs to be able to recognize it.
Agreed.
> [6] RPN and NRPN messages are 14-bits sent as MSB followed by LSB.
...
> But the problem here is by converting to float and sending float
> twice, you are sending 2 distinct parameter changes. Some gear and
> synths wouldn't behave that way. They might ignore the MSB and wait
> until the LSB arrives. Other gear might act on the MSB immediately.
> There is no way for the MIDI/GMPI translator to know!
You're right, there is no way to know. As discussed at length last week,
this is ALWAYS a problem. The simple heuruistic is to wait a small tick
for the LSB. Either way, I don't believe this to be a really significant
issue. Plugins could also do the buffering themselves:
* If the LSB is zero, buffer the change for n samples, if there is no
followup event, activate the MSB-only event. This is the same as what
hardware does now, right? With an event queue, you could even look
ahead in the queue to see if a second message for the same parameter
arrived.
> Summary: Musical performances are going to come into the system as
> MIDI messages 99% of the time. The only way to safely guarantee no
> loss of information is to translate MIDI 1:1. But if the translation
> is 1:1, why translate at all?
The reason to translate is to turn multiple sources (GMPI sequences, MIDI
input, OSC input, whatever) into a *single* protocol so that plugins only
need to handle that single protocol. If we can entirelty capture a MIDI
performance as GMPI events, then your plugin does not need to handle both
MIDI and GMPI, just GMPI.
Is that a fair goal, or does it just not matter?
> (And if the translation needn't be 1:1,
> how do you resolve the issues raised by [4], [5] and [6].)
Have my answers been fair?
----------------------------------------------------------------------
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:
