[gmpi] Re: MIDI: Common event coding

  • From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Thu, 24 Jun 2004 12:18:51 +0200

The more I think about it, the stranger it seems that even when it is now
shown that it is possible to transcode MIDI messages into GMPI messages
without loss, that the literal MIDI messages should still flow in the GMPI
graph.
I realize we could see this as a compromise, but it still seems strange to
me, and I really hope that we won't get the same old thing again from this:
in GMPI compliant host X you won't be able to chain GMPI plugin Y after GMPI
plugin Z in a successful way because Z uses the MIDI bytes only, and Y doess
it the right way using the GMPI messages, without generating MIDI bytes. I
really hope this won't be a problem and people won't start saying: "well,
plugin Z doesn't support MIDI, and that's way our plugin Y can't work the
way it should"...

That's why I also think Jack O'Quin's proposal (gmpi_encode_midi_exact and
approx) seems more appropriate:
- we won't have MIDI bytes flowing around for nothing in the future
- the people who really need the MIDI bytes will be able to do what they
want (and only they will need to do the conversions)
- we encourage people to use the GMPI messaging protocol

But if everyone feels good enough about the stapled MIDI bytes being there,
and that they will mostly be used for very special cases and in the
beginning as a "bridge" method, I'll go with the group. I'm already glad we
seem to have reached some point of agreement ;-)

Koen



On Thursday, June 24, 2004 9:24 AM [GMT+1=CET],
Tim Hockin <xxxthockin@xxxxxxxxxxxxx> wrote:

> On Thu, Jun 24, 2004 at 02:10:04AM -0500, Jack O'Quin wrote:
>>> back again at every plug, for no actual purpose.  For some classes of
>>> plug, that some of us here of think will be very common for the
>>> forseeable future, and for MIDI routing purposes, performing
>>> MIDI->GMPI->MIDI conversions at every plug is only inefficiency, pure
>>> cruft.  Stapling the source message is free to those who don't want to
>>> use it, so why disallow it?
>
> I think Chris's main point is that this is a concession we might have to
> be willing to make.  In exchange for having a single main protocol onto
> which everything maps, we have to accept that there are some developers
> (though I doubt it will be "very common") who will _NOT_ want to convert
> their MIDI plugins to use GMPI.
>
> Stapling MIDI onto messages allows them to keep their code MIDI centric.
> Hosts that do not staple MIDI onto messages, and messages without MIDI
> attached will just not work with those plugins.  And that's an outcome the
> NMiG camp might have to live with.
>
> Let's just hope that there will not be many plugins which rely on the
> stapled MIDI.  It would be a real shame if all the soft-synth
> manufacturers relied on the MIDI attachment, and don't put the effort into
> really supporting GMPI.
>
> What we *CAN* do is encourage and educate people to stop thinking of MIDI
> plugins and think of MUSIC plugins.  This will result in truly cross-host
> and generically useful plugins.  Synths will be more flexible and
> powerful, and MIDI processors will apply to all music equally, regardless
> of whether it cam from a MIDI source or not.
>
> And maybe, just MAYBE, by the time we get to specification or even before
> final stamping, the mindset of not being bothered to handle proper GMPI
> will have been overcome, and we can just rip that crutch out.  That's what
> it is, a crutch.  It's a crutch we might have to live with in the name of
> compromise.


----------------------------------------------------------------------
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: