[gmpi] Re: 3.15 MIDI
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 16 Jun 2004 08:03:00 -0400
This is getting way, way out of hand.
I want to back up a little to try to make it clearer what we are
discussing. First, an acronym: NMiG = No MIDI Inside GMPI. The
corollary: MiG.
The issue of MIDI-inside-GMPI really needs to be split into two parts:
1) the ability of plugins to receive, edit/process and/or send MIDI
data *without* being controlled by such data
2) the control of plugins using MIDI directly
Although these two are clearly related, they are not the same.
I suspect that most of the off- and on-list concern from the
MiG camp about plugins handling MIDI seems related to
(1). People have written interesting MIDI processors and/or generators
and their functionality is heavily tied into the semantics and syntax
of MIDI. Since they will ultimately be sending MIDI to external
non-GMPI devices, the authors want total control of the bytestream
they send. Of course, thats a bit of an illusion even in present
systems - the host is always the intermediary between the plugin and
any actual MIDI data transmission beyond the host - but the desire is
clear and somewhat defensible, even to an NMiG person like me.
Most of the on-list concern from the NMiG camp has been about (2). If
you know that MIDI messages might control a plugin's state, there is
no way to predict what the delivery of a MIDI message will do to the
plugin. Therefore, to this camp, even if the plugin can receive, edit
and send MIDI data, its unacceptable for the plugin to change its own
parameters as a result of receiving MIDI. MIDI in this scenario is a
data type just like audio - although its somewhat obvious that there
are plugins who might want change their parameters based on incoming
audio as well (self-adjusting noise removal, anyone?). I think this is
solvable using the model of public versus internal parameters -
incoming data never changes public parameters (the ones mediated by
the host).
I think it would be possible to design MIDI so that both camps were
reasonably satisfied by this. The parameter model in GMPI is already
sufficiently different from the way MIDI tends to be used that it will
be more work to attempt to use MIDI for parameter control, so most
plugin authors would likely try not to do it.
However, it poses a broader question. We've already agreed much much
earlier to limit the number of data types that can be exchanged inside
of GMPI. To satisfy the issue I've described in (1) above would
require a new data type - its not GMPI control data, its MIDI. I don't
find this very satisfactory. Here's what I see happening. Authors like
Koen who appreciate some of the issues with using MIDI to control
(virtual) instruments that are not well-modelled by MIDI ... will
likely end up writing plugins that take full advantage of GMPI's
control protocol, allowing users a finer degree of control over
things, and a better model of desired behaviour. Others will continue
to operate on MIDI data. One day, a user will want to connect the
OhMiGod Transmogrifier, a MIDI processor, to one of the NotMiGod
GranularConfabulator, a virtual instrument. And it won't work ... not
without a shim plugin to handle the data conversion between them.
That's an ugly scenario IMHO.
>> > > We've both exposed a personal requirement. I've all backed up mine.
>You
>> > > haven't. The best I can get from you is that "this is how it's always
>> > > been". That's not good enough.
>> >
>> > Well, I actually disagree. I don't think you've really backed up why
>MIDI
>>
>> MIDI is not expressive enough to be the main communication protocol for
>> plugins. It can't handle strings, it can't handle floats, it can't handle
>> blobs.
>
>I said "I don't think you've really backed up why MIDI shouldn't be in
>there".
>And I still think you haven't. If MIDI is not suitable for one task, then
>use some
>other protocol. Have GMPI allow supporting several control protocols.
>
>> If plugins support MIDI directly, then every plugin has to have MIDI
>> parsing code. This equates to wasted time, memory, and complexity.
>
>If you use some other encondig then you'd have to parse that. You could
>also provide a utility library with MIDI parsing code.
>
>> We've been discussing a model where the host manages all parameters. MIDI
>> would either bypass that mechanism, or would require more support to map
>> incoming CCs to parameters (so the host can snoop incoming CCs), or would
>> require some sort of extra helper API as part of GMPI.
>>
>> Having multiple control protocols is confusing to developers. Having
>> multiple control protocols that behave differently is confusing to users.
>> Ideally, GMPI will avoid those things.
>>
>> There's just a few reasons not to include MIDI as a raw protocol.
>
>Perhaps the model where the host manages all parameters as in keeping
>plugin state is flawed? You can't know exactly how a plugin responds
>to (N)RPNs, system exclusive or even CC.
>
>I don't think multiple protocols are confusing.
>
>> For Chris G. - SysEx can and should be passed to plugins essentially
>> unmolested. That's essentially a blob parameter to start with, and maps
>> nicely onto the parameter system we have been discussing.
>
>I don't see how it does.
>
>> > used the words "MIDI is a proven (industry) standard".
>>
>> ...with well-known shortcomings. Be fair.
>
>But it is a standard nonetheless. I think the importance of that cannot
>be overstated.
>
>> > > WHY would you prefer it? Because you have code to do it already?
>Because
>> > > you already understand it? Or is there some *real* thing that this
>allows
>> > > you to do that the other option doesn't?
>> >
>> > An example, MIDI allows realtime messages to occur within other
>messages.
>> > The exact position of such a realtime message might very wel get lost in
>> > translation.
>>
>> ? Every message in GMPI is timestamped. Positioning is absolutely
>> maintained.
>
>If you want to send the system realtime message immediately as it arrives
>then you could only send the message in which it occurs after that (since
>you don't have all the data yet). You could do this and have timestamps
>not be monotonically increasing, but you'd still have the drawback of the
>plugin not knowing another command was started before the realtime byte
>at the moment it receives the realtime byte.
>
>> > > Umm, do you write software? Are you any good at it? No offense
>meant,
>> > > but really, it just stands up and SCREAMS at me "BAD BAD BAD".
>> >
>> > Do you have any good reason besides questioning my ability to write
>> > good software? and telling me you are obviously right and I would see
>> > it too if only I were a better programmer?
>>
>> We've been spouting reasons all day. I apologize for attacking your
>> skills, that was wrong. However, it boggles my mind when something that
>> jumps out at me as bad design is praised. I just don't get it.
>
>MIDI is _not_ badly designed and I don't think having more than one
>control protocol should be a problem either.
>
>--ms
>
>
>
>----------------------------------------------------------------------
>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:
