[gmpi] Re: 3.15 MIDI (goals)
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 20 Jun 2004 22:43:01 -0400
>functionality seems to be unexamined. So, what about the 'Implements
>Total Recall/Undo' flag idea, Mike? But in any case, certainly the
>general idea you lay out here would help hosts that demand Total
>Recall/Undo to be able to handle MIDI-driven plugs and MIDI-in-Graph,
>though requiring both the list of wanted MIDI messages and in some
>cases the Actor component too could be seen as burdensome, and the
>host filtering of the MIDI stream could be seen as inefficient, a
>little. Probably plug developers who really care about displaying
>the 'Implements Total Recall/Undo' badge will do the work; others,
>maybe.
this is just ghettoization. if we're going to support such things,
lets just bag it and use:
kSupportsVST
kSupportsTDM
kSupportDirectX
define some standard packaging system and forget about the rest.
i have still not seen a single example of a use case in which the user
will face any difficulties from a NMiG+sysex scenario.
i have seen several examples of how GMPI suffers from silly complexity
if MIDI is allowed to exist in the graph as a control mechanism.
early in the requirements process, we defined GMPI as operating on
audio (e.g (and perhaps i.e.) PCM) data and on music (e.g. MIDI) data.
it was pointed out that (a) MIDI has some well-known limitations as a
music representation language and (b) music data and control of
plugins share much in common.
this led to the idea that the control data used to control plugins and
"music" data should be one and the same format, at least it did in my
head.
if the MiG fans can't agree that this makes sense, then i vote to
abandon any and all GMPI-specific data format. i vote to abandon any
GMPI control language (OSC or other), and require the use of MIDI as
the music representation language and the control protocol. we've been
told that there are ways to make MIDI do pretty much anything
(true), and that's what we should do.
why should we do this? because there are only 3 choices that i can
see:
a) we release a conceptually pure but MIDI-free GMPI, and
apparently nobody will use it
b) we release a kludged GMPI that has at least a half-dozen
hacks to allow the use of MIDI by plugins as well
as more flexible, more accurate and more expansive
GMPI control protocol. who knows who will use it - its
complex and hard to understand whether to use MIDI or
GMPI or what?
c) we release GMPI using MIDI for music data and control.
Maybe it works, maybe it doesn't. It has less
technical benefits than the GMPI control protocol
we've discussed, but its easier for people to use.
Maybe it works, maybe not. Either way, we'll know
next time around.
I really do mean this seriously. The mixed scheme that Chris keeps
cooking up strikes me as meritorious on every individual item, but a
nightmare when viewed as a whole. If we don't have what it takes to
ditch the baggage of MIDI, then lets not bag it. Trying to give the
world both what they want and what they need will end up in
frustation.
We should record that the requirements group found little technical
merit to MIDI over our own proposal, but felt that the existing
marketplace would not take up a MIDI free graph design. Because I
think thats really all that is being said here.
--p
----------------------------------------------------------------------
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:
