[gmpi] Re: Drilling down into MIDI->GMPI conversion
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 22 Jun 2004 11:22:34 -0400
>[1] Musicians can and will continue to record and perform music using
>MIDI gear. This means that any host application which allows the user
A few musicians can do this. The number of lyricons sold compared to
the number of saxophones is infinitesimally small. See my previous
post. Right now, musicians shut out of MIDI have no effective way to
use MIDI for this purpose. So while MIDI might theoretically be useful
for such purposes, it currently is not, and its
keyboard/percussion-centric model will have issues if it ever is.
>[1a] MIDI->GMPI conversion puts a new burden on a host app that wants to
>support GMPI music plugins. That could slow adoption.
Host apps are few and far between compared to plugins, but yes, it might.
>[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.
Trivial. I think you are thinking of OSC-like syntax too narrowly. We
will be sending messages around that contain multiple fields per
event. Just as a trivial example, every message has a timestamp in
addition to its data value(s). The OSC-like syntax that has been
discussed is an addressing system. Event delivery is done via function
call with a structure.
>[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?
Plugin uses wild-card addressing, preferably with *nix-shell-like
globbing, when "publishing" its inputs.
>[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.
Actually, not *that* predictably. The PB range is left up to the
implementation. Yes, they both bend but not necessarily at the same
rate.
>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.
Why would anyone ever propose anything else?
>[4a] (Hearkens back to [1].) MIDI is the de facto language for
>capturing music performances today, and it's not likely to change soon.
No, its the defacto language for capturing a limited class of
performance from keyboards and a few other types of controllers.
>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.
I don't understand why you anticipate problems with translating a
byte-code protocol like MIDI. Why would this cause problems?
>([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.)
Of course.
>[6] RPN and NRPN messages are 14-bits sent as MSB followed by LSB. It's
>legal for just MSB messages to be sent. Does this mean that the
>MIDI->GMPI translator will send one param change for MSB, followed by
>another for LSB? That's a problem: Suppose some RPN's current value is
>0. Now an external MIDI controller is about send a new value of 0x00FF.
Since they are broken in MIDI, they will remain broken in GMPI. We
can't fix the design of MIDI here - GMPI will have to continue the
borked tradition of having two separate controls for each "parameter"
- the MSB and the LSB.
----------------------------------------------------------------------
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:
