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.