Re: [Qtractor-devel] [Jack-Devel] Call for testing of MIDI Drivers in JACK 2

[Devin A. <de...@ch...>]

On Fri, Apr 15, 2011 at 5:59 AM, Paul Davis <pa...@li...> wrote:
> On Thu, Apr 14, 2011 at 2:35 PM, Devin Anderson
> <de...@ch...> wrote:
>
>> I think a better idea would be to convince authors of software that
>> uses ALSA MIDI to extend their applications with JACK MIDI
>> functionality.
>
> this is actually quite hard to do. as i've mentioned several times before:
>
>   * JACK MIDI is a very natural API to use if you use MIDI data
> inside process(), and a rather cumbersome one to use
>     if you are using MIDI data outside of the process callback
> (because you somehow have to get the data across
>     thread boundaries)
>
>  * ALSA MIDI is much easier to use if you don't need MIDI directly
> inside process(), but is very cumbersome to use
>    if you do (same reason as above)
>
> so, yes, for MIDI-driven synthesizers of all kinds, JACK MIDI is
> great. For other apps, its not so clearly a win.

So, the issue is getting thread data across boundaries.

Here is the main data structure that I used to get MIDI data across
thread boundaries for the various JACK 2 MIDI drivers:

    http://trac.jackaudio.org/browser/jack2/trunk/jackmp/common/JackMidiAsyncQueue.cpp
    http://trac.jackaudio.org/browser/jack2/trunk/jackmp/common/JackMidiAsyncQueue.h

(Pardon the camel case function names.  It's a JACK 2 convention.)

I've found it pretty easy to use when working on the MIDI drivers, and
have been able to use a semaphore to extend it when I need to block
until MIDI messages are available.

Is this an adequate solution?  If so, what would need to be done to
make it more accessible to coders that are having the problems with
JACK MIDI you described above?

-- 
Devin Anderson
devin (at) charityfinders (dot) com

CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/