[gmpi] Re: MIDI: Common event coding

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 23 Jun 2004 10:57:56 -0700

Tim replying to Chris:

> > { <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?

"Depending on event type, zero or more operands are also in the message. Operand count and data type of each depends on the event type."


Ron replying to Tim: 
Do we also eventually need to specify the endianess and format of floats in
these message fields?

You could if you wanted to. One reason that might make you want that more, depending on your idea of our scope, would be that then you'd essentially have a transportable data packet format, and once you have that, it can ride over any inter-machine transport you've got. But we should be sure we want to go there before putting more effort into that. If 'message' remains just a helpful metaphor, then I guess endianness is just another item in the per-platform GMPI profile.


Tim replying to Chris:
> > 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!

I think maybe either you misunderstood what I was saying, or you're not getting some of the idea.


Ron said:
Tim said:
Chris said:
- 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.

Of course I assume many MIDI messages are not meaningful for most GMPI plugins of the kind Tim's interested in writing. But because other people want to route and process general-case MIDI streams, and Mike wants the host to have total symbol-level knowledge of every plug's message, there needs to be a place in the coding dictionary for these messages. Otherwise GMPI as a pipe is broken. Saying plugs should not need to receive MTC does not mean MTC needs to be excluded from the coding, since even if I agreed with you about that, which I don't as plugs authors will think of some other good useful thing they want to do with MTC other than what you were expecting, there is MIDI routing to consider.

I expect most of the plugs that want to be able to deal with these particular MIDI messages will very likely ignore all parts of the message except the MIDI operand.

BTW, same reasoning supports: 
 > > 0xF1 - MTC Quarter Frame - This is a 'command' opcode addressed to
...snip...
> 0xFF - System Reset - This is a 'command' opcode addressed to the



Tim said: 
Chris said:
 > 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.

You misunderstand. You quote from the analysis of addressing in MIDI but assume it's a proposal for a limit in GMPI. No such limit is proposed.


Tim said: 
 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.

Again, the addressing mode description is from the analysis of MIDI, not the proposal for GMPI addressing.


Tim said:
 > So, as wonderful as this tastes, I have to ask: What happened to "WE MUST
 > HAVE MIDI!"?

In the proposal, we do have MIDI for the cases in which it's needed. I asked and asked and asked NiMG people to be clear about what exactly they meant by "no MIDI," and it never happened, sorry if you misunderstood that most of the discussion was (for me) about dissatisfaction with the reasoning that was proposed to back NMiG.


What happened 
 to MIDI processors and "studio routing"?  What happenend to all the
 arguments that MiG proposed.

All there.

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

  1. Home
  2. gmpi
  3. Archive
  4. 06-2004