[gmpi] MIDI: Stapling
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 2 Jul 2004 15:38:22 -0700
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
