<br><br><div class="gmail_quote">On Sat, Feb 23, 2013 at 3:19 PM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sat, Feb 23, 2013 at 01:09:28PM -0500, Paul Davis wrote:<br>
> On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll <<a href="mailto:jkroll@lavabit.com">jkroll@lavabit.com</a>> wrote:<br>
><br>
> ><br>
> > I don't know if there's such a tool. But AFAIK jack would only block<br>
> > the raw MIDI device when you use "-X raw" to use the raw MIDI driver in<br>
> > jack. Do you need that driver? If you don't, you can use the "seq"<br>
> ><br>
><br>
> to reiterate: if timing matters to you, do NOT use -X raw or -X seq.<br>
><br>
> use a2jmidid -e instead.<br>
<br>
</div></div>Are there any technical reasons why whatever method a2jmidi<br>
is using is not adopted for the backend ? Maybe it's just a<br>
matter of manpower, but OTOH this situation with the backend<br>
failing to do 'the right thing' has existed for quite some<br>
time now.<br></blockquote><div><br>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:<br><br>    * whether or not to provide a new way to load such clients (e.g. on the jackd command line)<br>
    * what to do about the dbus integration that is used in a2jmidid to pick up the arrival and departure of<br>           new MIDI interfaces<br><br>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.<br>
<br></div></div>