24 Nov
2008
24 Nov
'08
4:26 p.m.
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