11 Nov
2008
11 Nov
'08
8:56 a.m.
Le 11 nov. 08 à 13:48, Nedko Arnaudov a écrit :
"Alex Montgomery"
<apmontgomery(a)gmail.com> writes:
Good idea.
Currently jackctlmmc supports the
"play", "stop", and "rewind"
messages from
MMC, and I'm going to play with the code to see if I can add
support for
"locate" using jack_transport_locate() so that players can have a
primitive
seek-to type of function. I think that even this limited subset of
MMC
functionality is very desirable for linux audio engineers. I just
want to be
able to sit at my 8-track with my guitar and play/stop, rewind,
and maybe
seek around without having to keep clicking a mouse on a JACK app.
I already have git repository for jackctlmmc. If you are interested I
can make it public. Before importing it to git, I had the source of
the
quickly hacked tool in my local filesystem (no version control at
all).
I'm surprised that jackctlmmc doesn't
seem to be that widely used
(I can't
find any packages for it in the major linux distros, and it only
seems to be
distributed via source code) when it provides such useful
functionality. I'd
love to see it's functionality integrated into a GUI app like
QJackCtl
(which already has JACK transport buttons for play, rewind, fast-
forward)
instead of being a console application, but that's a subject for
another
email.
I think jackctlmmc can be made to be compilable as inprocess client
too.
Paul, Stephane and others, do you think we should have different
directories for jack1 and jack2 drivers/internal clients?
Drivera are definitively a lot different between jack1 and jack2
and internal clients a bit (a new "jack_internal_initialize"
function to be used when internal clients are loaded using the new
jack2 control API (or jackdbus))
So I don't see too much how they could *not* stay separated....
Stephane