[gmpi] Re: MIDI: Common event coding
- From: "Ron Kuper" <ronkuper@xxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 23 Jun 2004 06:49:17 -0400
> > { <address: index 6> <opcode: 2> <operand: float( 3500.9 )> }
>
> how do you idicate that the operand is going to be a float? Also, I'm
> assuming that the value 3500.9 is guaranteed to be withing the bounds of
> the parameter #6. Right?
Do we also eventually need to specify the endianess and format of floats in
these message fields?
> > All MIDI messages can also be losslessly encoded in the same form, as
>
> This is what NMiG people have been saying all along! Welcome to our camp!
> :) The kool-aid is pretty yummy, have some!
To me it seemed the MNiG people made claims to this effect, but no
demonstration that it could be done. Chris' tour de force here shows not
only how GMPI controls can extend MIDI, but how they can also do so by
building on and including the current space of MIDI message encodings.
Seeing is beleiving.
> > - System Common group (MTC QuarterFrame, Song Position Pointer, Song
> > Select, Tune Request, End of SysEx
>
> Not clear how these MIDI-isms will map to GMPI. How broken hearted would
> we all be if some of these got dropped in favor of GMPI-isms? Example:
> plugs should not need MTC - they should be slaving to the host. Could we
> reaonably drop MTC support for plugins?
I think we need to keep it. I might want to write an audio plugin that
resamples for purposes of external sync. Also, just for orthogonality, it's
nice to know that every known MIDI message has a place in GMPI space --
without exception.
> > 2.1.3. Channel Number Addressing - Some messages use only channel
> > number (0-15): Note On, Note Off, Channel Aftertouch, Program Change,
> > Pitch Bend Change
>
> Req #57 says "There may be an arbitrary number of channels per plugin".
> So this 0-15 assumption is right out. Even for MIDI, it is reasonable
> that the host would take incoming MIDI port 0 channel 12 and map it to a
> GMPI plugin's channel 199.
I agree. GMPI channel numbers should be unbounded. And by the way, should
they also be cookies instead of indices?
> I'd like to see this addressing mode go away. Can channel-targetted
> messages be handled as an extended case of control addressing? Req 57
> also says "channels need not be symmetric". Rather than make these
> MIDI-isms be first order opcodes, make them channelized parameters.
Channel, voice, stream, bus strip ... all of these are channel-like things
that are very common in the computer music world. I like channel numbers.
They let you make a parameter like volume generic across a space of like
objects.
> > 0xF1 - MTC Quarter Frame - This is a 'command' opcode addressed to
...snip...
> > 0xFF - System Reset - This is a 'command' opcode addressed to the
>
> I'd need clarification on some of these, and some (I think) we really
> don't want to send as far as the plugin.
I think we do and we should. See above.
> So, as wonderful as this tastes, I have to ask: What happened to "WE MUST
> HAVE MIDI!"? What happened to the lazy programmers who don't want to
> handle GMPI, and just want to use their existing MIDI code? What happened
> to MIDI processors and "studio routing"? What happenend to all the
> arguments that MiG proposed.
What happend is that Chris has proposed exacltly how MIDI gets mapped into
GMPI, in a way that crystallizes the 1:1 correspondence between MIDI events
and hiterto unspecified GMPI events. If we do anything like Chris'
proposal, I am satisfied that what we'll have is MIDI-like to enable
MIDI-like stream processing.
Let's put this across a wire and call it MIDI 2.0.<g> Did I just say that?
<VBG>
----------------------------------------------------------------------
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:
