• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: MIDI packet processing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MIDI packet processing


  • Subject: Re: MIDI packet processing
  • From: Chris Thomas <email@hidden>
  • Date: Mon, 20 Sep 2004 10:13:39 -0700


On Sep 16, 2004, at 3:12 PM, Doug Wyatt wrote:

On Sep 16, 2004, at 15:05, Scott Ruda wrote:
On Sep 15, 2004, at 4:11 PM, Doug Wyatt wrote:

On Sep 14, 2004, at 8:53, Scott Ruda wrote:
From: Doug Wyatt <email@hidden>
Multiple events per packet ARE allowed. You WILL receive them (e.g. from a USB MIDI interface) and you may create them.


Just don't use running status when writing a packet, or put realtime in between the bytes of a non-realtime message (except sysex). And you can make those assumptions when you parse packets.

I'm a bit confused now. According to the comments in the header file:


"In the case of system-exclusive messages, a packet may only contain a single message, or portion of one, with no other MIDI events."

Thanks for catching me -- I shouldn't have excepted sysex.

While realtime MAY interrupt sysex on a MIDI stream -- and in the "large-scale" streams moving around inside CoreMIDI -- within a single MIDIPacket, it may not.

Forbidding this has two advantages:
[1] when a realtime byte is occurring in the middle of a sysex message, it gets its own timestamp, which is extra desirable on realtime.
[2] you can indeed assemble/disassemble chunks of sysex with memcpy()

Thanks for clearing that up. I can now rip out the sysex block scanning/cleansing code I just put in... :-)


BTW, is this enforced by the CoreMIDI services, or is it the responsibility of the driver writers to conform to this specification? I.e. can I count on it, or should I be proactive and make no assumptions that all third party drivers do it the 'right' way?

If you've got defensive code in there, you might as well leave it in.

If you don't have defensive code, and you discover a misbehaving driver, I'll stick up for you in complaining to the author of the driver :)

As a driver author, my question back to you would be: where is this requirement documented? How am I, if starting from scratch, supposed to know this?


I mean, 4 years, no detailed documentation for either Core Audio or Core MIDI drivers. Surely Apple can do better.

Chris


--
Kerry's military experience isn't just "I served in the military," it's "I've seen war up close, and I've shown leadership in extremely difficult situations." Bush's military experience is, "I flew some planes, until I found better things to do." Duh.
-John-Paul

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: MIDI packet processing
      • From: Doug Wyatt <email@hidden>
References: 
 >Re: MIDI packet processing (From: Scott Ruda <email@hidden>)
 >Re: MIDI packet processing (From: Doug Wyatt <email@hidden>)
 >Re: MIDI packet processing (From: Scott Ruda <email@hidden>)
 >Re: MIDI packet processing (From: Doug Wyatt <email@hidden>)

  • Prev by Date: MatrixMixer Pulling
  • Next by Date: Re: IOAudioFamily : driver structure
  • Previous by thread: Re: MIDI packet processing
  • Next by thread: Re: MIDI packet processing
  • Index(es):
    • Date
    • Thread