jackd --sync -Xalsarawmidi -dalsa -r48000 -p256 a2jmidid -e still is the way I go, when using jack2. Regarding MIDI jitter I don't know if nowadays something better is implemented for jack2 and/or jack1 or if jack1 nowadays provide alsarawmidi too. I guess you need to test all available options on your own. IMO you shouldn't use an USB device if you care about MIDI jitter, this seems to be the weakest point in your chain.

On Thu, Sep 25, 2014 at 4:56 PM, Philipp Überbacher <murks(a)tuxfamily.org> wrote: the -X seq option in current JACK1 is just a backward compatible hack to allow qjackctl and other tools to invoke the relevant stuff. the actual implementation is nothing to do with the old -X seq code, and is actually a2jmidid converted into an internal client. Note that JACK2 could use this client too - its source code is even in the theoretically "shared" git repo for JACK tools.

On Fri, Sep 26, 2014 at 7:17 AM, Philipp Überbacher <murks(a)tuxfamily.org> wrote: the confusion here is that there are two sets of command line arguments when you start JACK: jackd [ SERVER OPTIONS ] -d BACKEND_NAME [ BACKEND OPTIONS ] for better or for worse, some of the option letters (e.g. -X or -p) can occur as either server options or backend options. in the "old" world, there was only -X as a backend option and it had two arguments ("seq" or "raw"). Both of them are basically not sensible to use because of the poor implementations they refer to. in the new world, the preferable use of -X is as a server option: jackd ... -X alsa_midi ... -d BACKEND .... BUT ... given the legacy of qjackctl and other control apps which don't know about this, I hacked jack1 so that it would look for the the -X seq argument as a **backend** option and treat that as if the user had used the new form. It would have been less confusing to have not done this, but that would have meant that it would be impossible/harder to use qjackctl to invoke this new MIDI bridge stuff, since it only knows about -X (seq|raw) as a backend option. Alles klar? Why isn't jack2 using the same client? It seems more convenient to just the developers of jack2 have so far not bothered to integrate the "shared" repository for jack tools into their source code. ps. I copied the use of -X as a server option to do this sort of thing from Jack2.

On 09/26/2014 04:12 PM, Philipp Überbacher wrote: on qjackctl settings, you can set the server prefix to "jackd -X alsa_midi" and leave the midi driver to "none", especially when NOT using "alsa" as the driver back-end. hth. cheers -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On September 26, 2014 05:26:15 PM Rui Nuno Capela wrote: Finally is it truly time to move on from the alsa seq and raw drivers? Rui, if ye have not already done so, would ye consider a wee update to qjctl to show these new slaves ? Since both Jack 1 and 2 now have slaves, perhaps a drop down list of the slaves with checkboxes beside each for choosing which ones to use. For good modern user experience and app development it would really help. Thanks! Tim.

On Fri, 26 Sep 2014 12:36:38 -0400 Paul Davis <paul(a)linuxaudiosystems.com> wrote: I confess I'm getting *more* confused about all of this :( I use up to 3 hardware MIDI ports for my compositions along with Rosegarden (which is ALSA MIDI only). Up to now I've been getting along quite well with this, as all the other software I use can work with ALSA. While I fully appreciate the issues around supporting both forms I'm getting a bit concerned by the push towards a JACK only system. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Fri, 26 Sep 2014, Will Godfrey wrote: As with audio, where the SW designer can support either ALSA, pulse or Jack for inputs or outputs, the SW designer can include either or both ALSA and/or Jack MIDI. a2jmidi could be useful to you as well as it would allow you to connect jack MIDI only SW to your ALSA MIDI only SW. True, you would have to run a jack server. From the SW designer's POV, jack provides a more stable MIDI even on systems that do not have the OS tweaked for ALSA MIDI. So why would they design for something more problematic? My personal experience (which is very small BTW) has been that the Jack MIDI API is much easier to use as well. The only downside (which I have not yet to run into) is that jack is limited in the size of the MIDI event it can deal with. An event would include a sysex and in jack this would be expected to be completed in one period (along with all audio processing too). -- Len Ovens www.ovenwerks.net

On Fri, Sep 26, 2014 at 10:13:28PM +0100, Harry van Haaren wrote: This is not entirely true. Jack's MIDI API does schedule events, but only within the current period. Anything that should happen later has to be remembered by the application, but this is not really rocket science. Any non-trivial app using MIDI is likely to maintain its own ordered list of events anyway. Standard data structures available from many libraries are available to do this if you don't want to write your own. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Fri, Sep 26, 2014 at 10:50:06AM -0400, Paul Davis wrote: And they are still using the completely broken resampling code from alsa_in/out wherever this function is needed. At my new work place (the research center of a very big corporation) I'm currently trying to push jack2 on Windows as a solution for some of the problems we're facing. We've been doing some tests this week, and the showstopper is the really abysimal performance of all of the jack2 tools that depend on resampling. If the jack2 devs don't fix this and do it very soon, then we will - by porting zita-ajbridge (where the 'a' will stand for ASIO) and zita-njbridge to Windows. And probably also by rewriting the the backend and make it use ASIO directly instead of going through Portaudio. Why on earth should a system such as Jack support anything but ASIO ? Tschuss, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Fri, Sep 26, 2014 at 03:58:06PM -0400, Paul Davis wrote: If Portaudio handles ASIO as it should be done, then it must contain all the code required to do this. So all that is needed is to re-use that while removing whatever unnecessary layers put on top of it. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)