<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
that said, i do think its a little odd to make this utility connect to<br>
JACK MIDI. any JACK MIDI client sending MMC to do transport control is<br>
just being stupid - it can control the transport directly. the<br>
interesting cases all involve the MMC source outside the computer, which<br>
makes using ALSA MIDI directly a bit more sensible (IMHO).<br>
<font color="#888888"></font></blockquote><div><br>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?<br>
<br>It's good news if ALSA is the better choice; it's how the code is currently written anyway.<br>

 <br>-- Alex<br></div></div><br>