[gmpi] Re: 3.15 MIDI
- From: "Martijn Sipkema" <m.j.w.sipkema@xxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 16 Jun 2004 13:14:45 +0100
> > > 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
Other related posts:
