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 17:49:58 +0100
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.
> 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.
Daniel
[1] http://caiaq.de/download/tmp/test.syx
[2] http://www.snoize.com/SysExLibrarian/
[3] http://www.snoize.com/MIDIMonitor/
> On Mar 16, 2009, at 5:25 , Daniel Mack wrote:
>
>> Hi,
>>
>> there's a nasty bug in SampleUSBDriver/Shared/MIDIParser.cpp which
>> causes the state machine to get confused when 0xf7 and 0xf0 are fed
>> into
>> the parser within a single message. Below is my patch - as reference
>> for
>> others and hopefully to be merged upstream for furture releases of
>> that
>> sample driver.
>>
>> @@ -90,8 +92,10 @@
>> // of whether one was sent (as per recommended practices)
>> mPacket.data[mPacket.length++] = 0xF7;
>> EmitPacket();
>> - if (c == 0xF7)
>> + if (c == 0xF7) {
>> + mDataRequired = 0;
>> return; // nothing more to do
>> + }
>> // other status bytes start a new packet
>> }
>>
>> 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