Re: Bug in SampleUSBDriver/Shared/MIDIParser.cpp
Re: Bug in SampleUSBDriver/Shared/MIDIParser.cpp
- Subject: Re: Bug in SampleUSBDriver/Shared/MIDIParser.cpp
- From: Daniel Mack <email@hidden>
- Date: Mon, 16 Mar 2009 18:16:34 +0100
On Mon, Mar 16, 2009 at 09:55:27AM -0700, Doug Wyatt wrote:
>> 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.
Ok, that explains it. But others might have blindly copied the sources
like I did and are equally affected now.
>> 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.
True. A 'continue' statement should fix that. I didn't hit that as our
hardware happens to break at a 0xf7 boundary as well, causing the next
bytes to be fed by a new call to FeedBytes().
> 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.
I can at least confirm that having a 'continue' there instead of a
'return' does not break it for me - the change seems right, though.
Daniel
_______________________________________________
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