Re: Bug in SampleUSBDriver/Shared/MIDIParser.cpp
Re: Bug in SampleUSBDriver/Shared/MIDIParser.cpp
- Subject: Re: Bug in SampleUSBDriver/Shared/MIDIParser.cpp
- From: Doug Wyatt <email@hidden>
- Date: Mon, 16 Mar 2009 09:55:27 -0700
On Mar 16, 2009, at 9:49 , Daniel Mack wrote:
On Mon, Mar 16, 2009 at 09:40:22AM -0700, Doug Wyatt wrote:
Thanks for sharing that. I'm staring at this and to figure out why
sysex
isn't more broken in, say, the USB class driver which may use this
source.
Don't know - I wondered as well and double-checked against the most
current sources that ship with Xcode, but the code hasn't changed for
years.
I've since checked; the USB driver has its own parser, so that's why
this hasn't been a huge thorn.
It seems that what would happen on receipt of 0xf7, 0xf0 is:
- f7 triggers EmitPacket and returns
- f0 also falls into the in-sysex case, triggers a superfluous
EmitPacket, but doesn't return
- starts a new sys-ex message
Jep, that's what I've seen, too. When pushing in two SysEx messages
right after each other, I saw the following sequence on the output:
- The 1st message
- The 1st message again with an additional 0xf7
- The 2nd message
Try to send my test.syx[1] with SysEx Librarian[2] and monitor it with
MIDI Monitor[2] to see the effect. I didn't try with any other
interface, but it was certainly broken in the sources.
OK, clearly mDataRequired should get zeroed after F7, but the next
thing I wonder is, why should it return after F7? It seems that the
caller ought to be able to pass more bytes immediately following an
F7, possibly starting another message.
I'd just go off and make changes but since you seem to be in a good
position to test it, maybe you'd like to check that out too.
thanks again,
Doug
_______________________________________________
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