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