Alex Montgomery wrote: > > 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
The jackd -dalsa -X option seems to make clients available for both QjackCtl tabs, but e.g. Qtractor's connection GUI only shows ALSA.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
