On Sat, Feb 23, 2013 at 3:19 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:

On Sat, Feb 23, 2013 at 01:09:28PM -0500, Paul Davis wrote:
> On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll <jkroll@lavabit.com> wrote:
>
> >
> > I don't know if there's such a tool. But AFAIK jack would only block
> > the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
> > jack. Do you need that driver? If you don't, you can use the "seq"
> >
>
> to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
>
> use a2jmidid -e instead.

Are there any technical reasons why whatever method a2jmidi
is using is not adopted for the backend ? Maybe it's just a
matter of manpower, but OTOH this situation with the backend
failing to do 'the right thing' has existed for quite some
time now.

it is just a question of manpower. i already did factor out most of the a2j* code into an internal client that jackd could load. the problems remaining:

    * whether or not to provide a new way to load such clients (e.g. on the jackd command line)
    * what to do about the dbus integration that is used in a2jmidid to pick up the arrival and departure of
           new MIDI interfaces

I'm not sure that dbus is actually necessary for this - i think the sequencer API has its own way of announcing new clients (and the departure of existing ones) - but I have not investigated it enough to come to a conclusion.