Re: [Jack-Devel] CoreMIDI driver bug fix

PrevNext  Index
DateSun, 03 Mar 2013 14:46:10 -0800
From Devin Anderson <[hidden] at gmail dot com>
ToChristian Schoenebeck <[hidden] at crudebyte dot com>
CcJack devel <[hidden] at lists dot jackaudio dot org>
Follow-UpStéphane Letz Re: [Jack-Devel] CoreMIDI driver bug fix
Hi Christian,

On Sun, Mar 3, 2013 at 2:39 PM, Christian Schoenebeck
<[hidden]> wrote:
> On Saturday 02 March 2013 20:29:53 Devin Anderson wrote:
>> That's interesting.  The iOS CoreMIDI spec says the same thing as the
>> MacOSX CoreMIDI spec.  Is that MIDI coming from the hardware driver,
>> or from other CoreMIDI applications?  Has a bug been filed against
>> either CoreMIDI or whatever is sending the MIDI messages?
>
> It sais the same, because like many APIs in iOS, the CoreMIDI API seems to be
> copied by Apple as it is. In many iOS API docs you find things like
> "Availability: Available in OS X v10.5 and later" - full stop, not even
> mentioning any iOS version at all.
>
> The issue with "running status" seems to be emitted by the iOS hardware
> driver. I never encountered it myself, since I don't have a keyboard or MIDI
> controller which sends with running status ATM. I'm trusting here on couple
> end users who reported this "running status" issue to exist on iOS. And in
> fact there were some other end users who reported exactly these symptoms on
> iOS (numerous dropped note on / off events). The reported keyboards (I still
> find in my mails) which would have that issue were: Alesis 49, some Novation
> keyboard and "maybe" Akai synth station (not sure about the latter). These
> were all end user reports. Hardware defects can be exluded, since the users
> reported those keyboards to work with other, more mature CoreMIDI iOS apps.
>
> I haven't filed a bug at Apple's bug tracker system, nor checked if there is
> one already. So far I haven't even proofed that this bug really exists.

Perhaps the numerous dropped note-on/note-off events are due to the
multiple message/packet bug, and have nothing to do with running
status.  I can't confirm the possibility either way, as I don't have
access to a Mac or an iPhone.

> I just pushed some temporary code for handling multiple events in one
> MIDIPacket. Maybe Stéphane can merge it to the official git server again.
> It's quite some amount of code now. It could be reduced to only few lines, by
> splitting JackCoreMidiInputPort::ProcessCoreMidi() into 2 methods (one method
> only iterating over events, calling each time the 2nd method which is
> guaranteed to receive only data of exactly one event). However I think it's
> not worth it at this point, since I expect the whole MIDI parser code in
> JackCoreMidiInputPort to be dropped in favor of using
> JackMidiRawInputWriteQueue very soon.

Excellent. :)

>> If you plan on adding the JackMidiRawInputWriteQueue, then I'd like to
>> make a suggestion.  The alsarawmidi driver and the FFADO driver use
>> the JackMidiRawInputWriteQueue.  If you need a reference on how to use
>> the driver, you can look at those drivers.  The alsarawmidi driver is
>> probably more relevant because it uses the two thread scheme to handle
>> MIDI messages, just like CoreMIDI.
>
> Ok, I try to find a bit of time for that task in probably two weeks.

Awesome!  When I wrote the code, I didn't have access to a Mac, so I
couldn't debug (or even compile) what I wrote.  Just a warning, as
there could be other bugs lurking in the code.

>> If you have any other questions regarding the MIDI queue system,
>> please send me a message.  I'm happy to help. :)
>
> Ok, I will get back at that. :)

:)

-- 
Devin Anderson
surfacepatterns (at) gmail (dot) com

blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
PrevNext  Index

1362350781.12632_0.ltw:2,a <CAG7zqTrh=x+iWsLXqQqCzxJ+1uxUHNtD-rFKq88A81mLj+desQ at mail dot gmail dot com>