that said, i do think its a little odd to make this utility connect to
JACK MIDI. any JACK MIDI client sending MMC to do transport control is
just being stupid - it can control the transport directly. the
interesting cases all involve the MMC source outside the computer, which
makes using ALSA MIDI directly a bit more sensible (IMHO).

Wow, really? I thought that JACK (via ALSA on Linux, but this is implementation dependent) supported access to external ports anyway. We were going to switch to JACK midi because it is theoretically more portable (to OS X, say) and more JACK compliant (which a JACK transport app should be), without adding any dependencies (obviously we are already using the JACK libraries since jackctlmmc is a JACK client.).  I assumed that the only repercussion of switching to JACK midi would be that the user would have to make the connection to the external ports using a JACK controller instead of alsa utilities like aconnect. In the case of people using an app like QJackctl, the application would simply hop to the JACK tab instead of the ALSA tab. Is that not true? Are there other complications that could stop users from connecting to external midi devices?

It's good news if ALSA is the better choice; it's how the code is currently written anyway.
 
-- Alex