[gmpi] Re: MIDI: Stapling

Well, there are a couple of things in your reasoning that I'm not sold by
either, but as said, let's not re-open the discussion (I think it's clear by
now that there are several distinct ways of thinking about these issues).

Anyway, the purpose of my post is also to let you know that I'll be away to
some hot (and wet) Asian country until the 1st of August. Don't know about
you guys, but you won't get much feedback from me during the next month. See
you later in August.

Koen


On Saturday, July 03, 2004 12:38 AM [GMT+1=CET],
Chris Grigg <xxxgmpi-public@xxxxxxxxxxxxxxxxx> wrote:

> Back again, sorry for the absence.  I'm going to try to roll together
> responses to all the comments on stapling original MIDI to those GMPI
> messages that started out as MIDI events.
>
> I think I see five arguments against stapled MIDI (SM):
>
> 1. It's inefficient/cumbersome architecturally to carry the SM along
> with the pure GMPI message
> 2. Most plugs will prefer pure GMPI over SM, so for most situations
> supporting SM is on balance inefficient
> 3. Plug developers will use the SM) instead of the pure GMPI part of
> the message
> 4. Plugs that use only the SM will fail, causing user
> confusion/frustration
> 5. GMPI's equivalent to MIDI note-on may be spread over multiple GMPI
> messages, so which one gets the SM?
>
> Some of these contradict one another, but that's OK, they didn't all
> come from the same person.  However I'm not sold by any of them.
> Taking them one at a time:
>
>
> 1. It's inefficient/cumbersome architecturally to carry the SM along
> with the pure GMPI message
>
> Depends on the implementation.  We already have stapled MIDI SysEx,
> so there will be some sort of mechanism in place, and I see no reason
> why the same mechanism couldn't also handle the 1-, 2-, and 3-byte
> MIDI messages.  The mechanism could well involve the host holding one
> copy of the SM, it wouldn't necessarily have to appear literally in a
> message packet (though for renderfarm-type distributed architectures
> that would have clear advantages).
>
>
> 2. Most plugs will prefer pure GMPI over SM, so for most situations
> supporting SM is on balance inefficient
>
> The premise is untestable, there is no way to know that most plugs
> will in fact prefer pure GMPI.  I really doubt it will be true,
> especially at first.  Also nearly all hosts that are music event
> sequencers are already using heavily MIDI-modelled event
> representation internally, often actual MIDI bytes, even if
> automation track data is stored as floats.  Saying it's better for
> developers to use pure GMPI is not really an answer to the factual
> issue of what % of real-world plugs will prefer pure GMPI vs. SM.
>
>
> 3. Plug developers will use the SM instead of the pure GMPI part of the
> message
>
> I agree this is probably true, at least at first, but don't see that
> this is in any sense a problem, much less a reason to exclude SM --
> quite the opposite, if people genuinely want to do this, we should be
> responsive to that and give it to them.  If pure GMPI really is
> better across the board, which I don't necessarily dispute, then
> there will be a natural migration away from SM over time, and there
> will be future GMPI versions, at which time deprecation of SM will,
> doubtless, be discussed.
>
>
> 4. Plugs that use only the SM will fail, causing user
> confusion/frustration
>
> The premise makes unwarranted assumptions.  Consider an existing VST2
> plug that processes MIDI; assume the developer wants to port to GMPI
> because there's a user community that wants to keep using those plugs
> as hosts start to support GMPI.  The plug looks for stapled MIDI in
> incoming GMPI events; if there's SM there, it uses it (very
> efficient, minimal disruption, status quo); if no SM is there, plug
> has three choices: a) Strict-convert the GMPI to MIDI and use the
> reconstituted MIDI message (wasteful for the huge number of cases in
> which the message originated as live-from-HW or stored-in-sequences
> MIDI, but at least possible); b) Ignore the event and do nothing
> (resulting in user complaints, so either it's eventually fixed, or
> the developer just doesn't care so there's nothing you can do about
> it anyway); or c) Complain to the host somehow, so the host can
> automatically do the strict-conversion  before the plug sees the GMPI
> message.  Alternate option: At init time, plug has some way to let
> the host know that for a given parameter, "Wants Stapled MIDI" and
> again the host auto-provides the SM.
>
>
> 5. GMPI's equivalent to MIDI note-on may be spread over multiple GMPI
> messages, so which one gets the SM?
>
> To me, this is the only one of the five that seems to have any actual
> potential issue at the core, however a) Premise is untestable, since
> have neither requirements nor design proposals for note events in
> pure GMPI; and b) Multiple simple workarounds suggest themselves,
> e.g. if there are three GMPI messages with the same note-id and the
> same stapled MIDI, then a plug that only cares about the MIDI can
> launch the whole note on the first GMPI message and ignore the other
> ones (so it doesn't matter whether the others have SM or not); if the
> host knows that a plug wants SM, there may be no need to even
> generate the additional GMPI messages; etc.
>
> -- Chris G.
>
> ----------------------------------------------------------------------
> 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: http://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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: