9 Nov
2008
9 Nov
'08
11:21 a.m.
Hello,
I'm guessing from the research I've done online and from the lack of
responses to my LAU message (
http://www.nabble.com/Slaving-jack-to-MMC-MTC-to20357929.html ) that JACK
does not currently support slaving to external (or internal?) devices via
MMC/MTC. I'm a C/C++ developer by trade, so I'm happy to get my hands dirty,
but I wanted to know what other work, if any, has been done on this front.
I've been told that both Rosegarden and Ardour can sync to MTC, but that
they cannot then drive JACK transport in that mode. Would it be difficult to
move this code over to JACK? Is there a reason this in't desirable?
There's a small program called jackctlmmc that seems to do want I want, but
it's a bit limited (seems pretty hardcoded) and I think that such a
desirable feature should be integrated into a more widely used program. Any
thoughts?
Thanks,
-- Alex
9 Nov
9 Nov
11:36 a.m.
On Sun, 2008-11-09 at 15:21 +0000, Alex Montgomery wrote:
Hello,
I'm guessing from the research I've done online and from the lack
of responses to my LAU message
( http://www.nabble.com/Slaving-jack-to-MMC-MTC-to20357929.html ) that
JACK does not currently support slaving to external (or internal?)
devices via MMC/MTC. I'm a C/C++ developer by trade, so I'm happy to
get my hands dirty, but I wanted to know what other work, if any, has
been done on this front. I've been told that both Rosegarden and
Ardour can sync to MTC, but that they cannot then drive JACK transport
in that mode. Would it be difficult to move this code over to JACK? Is
there a reason this in't desirable?
JACK does not and will not support varispeed. Therefore slaving to MTC
is going to be pretty limited. MMC also sends some speed commands that
could not be supported by JACK.
There's a small program called jackctlmmc that
seems to do want I
want, but it's a bit limited (seems pretty hardcoded) and I think that
such a desirable feature should be integrated into a more widely used
program. Any thoughts?
what does "hardcoded" mean?
10 Nov
10 Nov
11:01 a.m.
Hello and thanks for the response :)
I've inlined my responses below:
JACK does not and will not support varispeed. Therefore slaving to MTC
I made that comment in ignorance. I didn't see a place in the code where you
could choose which MIDI device/port you were reading from, so I assumed that
it just took the first registered one or hardcoded (specified in code
instead of parameters passed into the program) a particular port. On closer
inspection, it seems that you either have to patch a midi port to the
application via JACK so it knows which one to read from, or it just reads
from all alsa midi signals, either of which is perfectly reasonable. I'm new
to the JACK and ALSA APIs, and I'm still waiting on a cable order to get my
8-track to talk to my PC, so I can't really test to see how this stuff
works.
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'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.
Thanks for your reply,
-- Alex
is going to be pretty limited. MMC also sends some
speed commands that
could not be supported by JACK.
I understand, but I think limited MTC support is better than nothing. That
being said, I don't think it's necessary to change JACK for this purpose,
jackctlmmc's approach of being a jack compliant app that can drive JACK
transport by listening to MMC signals seems like an elegant approach.
There's a small program called jackctlmmc
that seems to do want I
want, but it's a bit limited (seems pretty hardcoded) and I think that
such a desirable feature should be integrated into a more widely used
program. Any thoughts?
what does "hardcoded" mean? 
11:28 a.m.
Le 10 nov. 08 à 16:01, Alex Montgomery a écrit :
Hello and thanks for the response :)
I've inlined my responses below:
JACK does not and will not support varispeed. Therefore slaving to MTC
is going to be pretty limited. MMC also sends some speed commands that
could not be supported by JACK.
I understand, but I think limited MTC support is better than
nothing. That being said, I don't think it's necessary to change
JACK for this purpose, jackctlmmc's approach of being a jack
compliant app that can drive JACK transport by listening to MMC
signals seems like an elegant approach.
I think this kind of tools is a good candidate to be developed as an
"in server" JACK client. With the dbus based dynamic access of
available "in server" clients installed on a machine, it will be
quite easy to load/unload this kind of tool when needed (Netjack2
uses this model of "in server" clients).
Stéphane
There's a small program called jackctlmmc
that seems to do want I
want, but it's a bit limited (seems pretty hardcoded) and I think
that
such a desirable feature should be integrated
into a more widely
used
program. Any thoughts?
what does "hardcoded" mean?
I made that comment in ignorance. I didn't see a place in the code
where you could choose which MIDI device/port you were reading
from, so I assumed that it just took the first registered one or
hardcoded (specified in code instead of parameters passed into the
program) a particular port. On closer inspection, it seems that you
either have to patch a midi port to the application via JACK so it
knows which one to read from, or it just reads from all alsa midi
signals, either of which is perfectly reasonable. I'm new to the
JACK and ALSA APIs, and I'm still waiting on a cable order to get
my 8-track to talk to my PC, so I can't really test to see how this
stuff works.
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'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.
Thanks for your reply,
-- Alex
12:08 p.m.
New subject: [Jack-Devel] Jack MTC/MMC slaving
Le 10 nov. 08 à 16:01, Alex Montgomery a écrit :
> > There's a small program called jackctlmmc
that seems to do want I
> > want, but it's a bit limited (seems pretty hardcoded) and I think that
> > such a desirable feature should be integrated into a more widely used
> > program. Any thoughts?
On Mon, Nov 10, 2008 at 9:28 AM, Stéphane Letz <letz(a)grame.fr> wrote:
I think this kind of tools is a good candidate to be
developed as an "in
server" JACK client. With the dbus based dynamic access of available "in
server" clients installed on a machine, it will be quite easy to load/unload
this kind of tool when needed (Netjack2 uses this model of "in server"
clients).
Stephane has a good point.
But, implementing it as an external client probably makes sense right
now. It should be simpler to support both jackd and jackdmp servers
with the same code that way.
--
joq
12:46 p.m.
New subject: [Jack-Devel] Jack MTC/MMC slaving
On Mon, 2008-11-10 at 10:08 -0600, Jack O'Quin wrote:
On Mon, Nov 10, 2008 at 9:28 AM, Stéphane Letz
<letz(a)grame.fr> wrote:
agreed. and it may be easier to remain that way if users want easy
control over MMC ID and a few other parameters related to MMC handling.
however the appeal of using some "parameter setting protocol" to set
this in a client that is otherwise invisible is fairly apparent.
--p
I think this kind of tools is a good candidate to
be developed as an "in
server" JACK client. With the dbus based dynamic access of available "in
server" clients installed on a machine, it will be quite easy to load/unload
this kind of tool when needed (Netjack2 uses this model of "in server"
clients).
Stephane has a good point.
But, implementing it as an external client probably makes sense right
now. It should be simpler to support both jackd and jackdmp servers
with the same code that way.
24 Nov
24 Nov
1:28 p.m.
I think this kind of tools is a good candidate to be
developed as an "in
server" JACK client. With the dbus based dynamic access of available "in
server" clients installed on a machine, it will be quite easy to load/unload
this kind of tool when needed (Netjack2 uses this model of "in server"
clients).
Ok, so Nedko and I got a release out that supports goto/locate MMC messages
and command-line parameters. We're going to switch it over to using JACK
midi instead of ALSA midi next. Should we start thinking about making this
an "in server" client now? Could someone familiar with this stuff comment on
this?
Thanks,
-- Alex
1:35 p.m.
On Mon, Nov 24, 2008 at 11:28 AM, Alex Montgomery
<apmontgomery(a)gmail.com> wrote:
I recommend making it a normal external client. That will be easier
to code and test, and easier to make work with both jack1 and jack2
servers.
--
joq
I think this kind of tools is a good candidate to
be developed as an "in
server" JACK client. With the dbus based dynamic access of available "in
server" clients installed on a machine, it will be quite easy to load/unload
this kind of tool when needed (Netjack2 uses this model of "in server"
clients).
Ok, so Nedko and I got a release out that supports goto/locate MMC messages
and command-line parameters. We're going to switch it over to using JACK
midi instead of ALSA midi next. Should we start thinking about making this
an "in server" client now? Could someone familiar with this stuff comment on
this?
1:42 p.m.
Le 24 nov. 08 à 18:35, Jack O'Quin a écrit :
On Mon, Nov 24, 2008 at 11:28 AM, Alex Montgomery
<apmontgomery(a)gmail.com> wrote:
I recommend making it a normal external client. That will be easier
to code and test, and easier to make work with both jack1 and jack2
servers.
--
joq
Maybe you can structure the code to have the "parameter parsing" part
clearly separated from "opening/activating the jack client" part. Then
it will be easier to make it as an internal client.
Stephane
I think this kind of tools is a good candidate to
be developed as
an "in
server" JACK client. With the dbus based dynamic access of
available "in
server" clients installed on a machine, it will be quite easy to
load/unload
this kind of tool when needed (Netjack2 uses this model of "in
server"
clients).
Ok, so Nedko and I got a release out that supports goto/locate MMC
messages
and command-line parameters. We're going to switch it over to using
JACK
midi instead of ALSA midi next. Should we start thinking about
making this
an "in server" client now? Could someone familiar with this stuff
comment on
this? 
1:53 p.m.
Stéphane Letz wrote:
Le 24 nov. 08 à 18:35, Jack O'Quin a écrit :
I don't know how you coders have to handle things, but for users it will
be more comfortable, if such functions are not some external
applications, it should be part of JACK, if this won't cause to much
troubles for you.
On Mon, Nov 24, 2008 at 11:28 AM, Alex
Montgomery
<apmontgomery(a)gmail.com> wrote:
I recommend making it a normal external client. That will be easier
to code and test, and easier to make work with both jack1 and jack2
servers.
--
joq
Maybe you can structure the code to have the "parameter parsing" part
clearly separated from "opening/activating the jack client" part. Then
it will be easier to make it as an internal client.
Stephane I think
this kind of tools is a good candidate to be developed as
an "in
server" JACK client. With the dbus based dynamic access of
available "in
server" clients installed on a machine, it will be quite easy to
load/unload
this kind of tool when needed (Netjack2 uses this model of "in
server"
clients).
Ok, so Nedko and I got a release out that supports goto/locate MMC
messages
and command-line parameters. We're going to switch it over to using
JACK
midi instead of ALSA midi next. Should we start thinking about
making this
an "in server" client now? Could someone familiar with this stuff
comment on
this?
2:52 p.m.
On Mon, Nov 24, 2008 at 11:52 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
I don't know how you coders have to handle things,
but for users it will
be more comfortable, if such functions are not some external
applications, it should be part of JACK, if this won't cause to much
troubles for you.
Being part of JACK is completely independent of whether it is coded as
an internal or external client.
I don't think there will be any objection to distributing it in the
JACK tools directory.
--
joq
1:36 p.m.
Alex Montgomery wrote:
I think this kind of tools is a good candidate to be developed as
an "in server" JACK client. With the dbus based dynamic access of
available "in server" clients installed on a machine, it will be
quite easy to load/unload this kind of tool when needed (Netjack2
uses this model of "in server" clients).
Ok, so Nedko and I got a release out that supports goto/locate MMC
messages and command-line parameters. We're going to switch it over to
using JACK midi instead of ALSA midi next. Should we start thinking
about making this an "in server" client now? Could someone familiar
with this stuff comment on this?
Thanks,
-- Alex
I'm not familiar with MMC and I'm less familiar with Linux MIDI, because
of to much troubles, but I know that I need to sync an Atari ST with
Linux MIDI by MTC and this isn't possible for all applications. It would
be good if JACK transport can be master and slave for song position
pointer and also timing clock. ALSA MIDI is more important than JACK MIDI.
Cheers,
Ralf
1:55 p.m.
On Mon, 2008-11-24 at 18:36 +0100, Ralf Mardorf wrote:
I'm not familiar with MMC and I'm less
familiar with Linux MIDI, because
of to much troubles, but I know that I need to sync an Atari ST with
Linux MIDI by MTC and this isn't possible for all applications. It would
be good if JACK transport can be master and slave for song position
pointer and also timing clock.
MIDI SPP and MIDI Clock are unrelated to MMC.
it is not possible to interpet either of them without tempo/meter
information - they do not refer to an audio-based timeline, only a
"musical time" (bars|beats|ticks).
ALSA MIDI is more important than JACK MIDI.
they are not divided from each other. JACK MIDI is a cleaner API and
allows much simpler sharing of MIDI data between audio applications. the
fact that few apps directly support it at present isn't very significant
since you can bridge from ALSA to JACK MIDI and back again.
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).
--p
2:12 p.m.
Paul Davis wrote:
MIDI SPP and MIDI Clock are unrelated to MMC.
it is not possible to interpet either of them without tempo/meter
information - they do not refer to an audio-based timeline, only a
"musical time" (bars|beats|ticks).
Sorry, you're right, the applications have to handle informations about
e.g. the actual song position by the sum of 1/16 notes, from the
starting point of a song. OT: Unfortunately Ardour as master, can sync
an Atari Cubase, but not as slave, while Rosegarden as master, can sync
an RX21, but not an Atari Cubase.
the interesting cases all involve the MMC source
outside the computer,
which makes using ALSA MIDI directly a bit more sensible (IMHO).
That is, what I was thinking of.
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
4:40 p.m.
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.
5:42 p.m.
On Mon, 2008-11-24 at 21:40 +0100, Ralf Mardorf wrote:
Alex Montgomery wrote:
Not relevant, because using Qtractor as the MMC source is silly :)
the point is that yes, JACK provides bridges to the outside world (via
phsyical MIDI ports), but these are more "expensive" than using ALSA. if
the goal is to get the incoming data into jackmmcctl ASAP, then ALSA (or
other native MIDI layer) makes more sense.
if you want an idea about common MIDI port APIs (including JACK, ALSA
and CoreMIDI and even OSS) check libs/midi++ in the ardour tree).
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. 
6:33 p.m.
Paul Davis wrote:
On Mon, 2008-11-24 at 21:40 +0100, Ralf Mardorf
wrote:
qtractor doesn't know about jack-midi. all midi stuff is done through
alsa-seq. the MIDI tab in qtractor connections widget is indeed
identical to qjackctl's ALSA tab.
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. Not relevant, because using Qtractor as the MMC source
is silly :)
otoh, maybe silly because qtractor is also fully mmc and jack-transport
aware. iow, qtractor and jackmmcctl will probably step on each other
toes. hmmm...
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
6:37 p.m.
On Mon, 2008-11-24 at 22:33 +0000, Rui Nuno Capela wrote:
no, silly because if QTractor wants to control JACK transport, its not
going to plan on doing it by sending MMC. thats all i mean. the things a
user wants to send MMC from to control JACK will be *outside* JACK, i am
fairly certain of that.
--p
Not relevant, because using Qtractor as the MMC
source is silly :)
otoh, maybe silly because qtractor is also fully mmc and jack-transport
aware. iow, qtractor and jackmmcctl will probably step on each other
toes. hmmm...
7:15 p.m.
no, silly because if QTractor wants to control JACK
transport, its not
going to plan on doing it by sending MMC.
That's true, but if JACK transport should send/receive MMC by MIDI
to/from an external device, there is the need to connect the ports, that
transmits/receive the MMC commands, to the hardware MIDI out/in ports.
So it would be fine, if this is possible by the Qtractor GUI, resp. it's
silly, because I didn't know that Qtractor is transmitting MMC by itself
and that's why there isn't the need to do this by Qtractor. BUT if JACK
will be the source and receiver for MMC, than applications like Qtractor
don't need to be able to know MMC by them self. If this is only done by
JACK and it's fine, than nobody has to fear, that an application is a
broken MMC master/slave. Also it's silly to run more than one
application, that is able to know MMC, if they all are JACK transport
compatible. It's antithetic to say Linux is flexible, because we can
choose the applications that we need, without running things we don't
need and on the other side, we run more than one application, that is
MMC able. JACK should be the instance that knows MMC and not the HD
recorders and sequencers.
8:25 p.m.
Paul Davis wrote:
On Mon, 2008-11-24 at 22:33 +0000, Rui Nuno Capela
wrote:
no, silly because if QTractor wants to control JACK transport, its not
going to plan on doing it by sending MMC. thats all i mean. the things a
user wants to send MMC from to control JACK will be *outside* JACK, i am
fairly certain of that.
ah, yes, but qtractor will also do the evil thing and spit out some mmc
when it detects jack transport state has changed somehow outside its own
control. eg. press play in qjackctl => jack transport starts rolling =>
qtractor starts rolling too => qtractor sends out mmc play command and
probably jackmmcctl will do the same :)...
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Not
relevant, because using Qtractor as the MMC source is silly :)
otoh, maybe silly because qtractor is also fully mmc and jack-transport
aware. iow, qtractor and jackmmcctl will probably step on each other
toes. hmmm...
25 Nov
25 Nov
6:02 a.m.
ah, yes, but qtractor will also do the evil thing and
spit out some mmc
when it detects jack transport state has changed somehow outside its own
control. eg. press play in qjackctl => jack transport starts rolling =>
qtractor starts rolling too => qtractor sends out mmc play command and
probably jackmmcctl will do the same :)...
Actually, jackctlmmc only responds to the ports/programs that you've
explicitly connected it to, so your scenario wouldn't cause problems as long
as you only connected jackctlmmc to your external midi port. If you were
foolish enough to manually connect it to external ports and every other
application running on your system, then you would deserve whatever strange
behavior you received :P
-- Alex
24 Nov
24 Nov
7:25 p.m.
qtractor and jackmmcctl will probably step on each
other
toes. hmmm...
You are right Nui. A user like me is just a stupid user who will make
music. Maybe someone like me runs JACK, Ardour and Qtractor and wants to
control an external machine by MMC. We don't read all the Wikis and
FAQs, we should do this, but we don't do it. What will happen, if
someone pushes "play" by QjackCtl and JACK, Ardour and Qtractor send
MMC, maybe because of bugs at different times, with a short delay?
11 Nov
11 Nov
8:50 a.m.
"Alex Montgomery" <apmontgomery(a)gmail.com> writes:
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?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
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
9 a.m.
Stéphane Letz <letz(a)grame.fr> writes:
Le 11 nov. 08 à 13:48, Nedko Arnaudov a écrit :
So we should install jack2 drivers and internal clients in
<prefix>/lib/jack2 instead of <prefix>/lib/jack ?
Thus out of tree internal clients will work for version they were
compiled. Still this does not fix the issue binary interface changes
between versions.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
"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....
10:34 a.m.
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).
Yeah, if you could make it public via git that'd be very helpful. I
personally won't have time to code until the weekend unfortunately.
Currently jackctlmmc supports the "play",
"stop", and "rewind"
For now I just want to add support for the MMC "Locate/Go to" message 44 (
http://en.wikipedia.org/wiki/MIDI_Machine_Control ), not use
jack_transport_locate to try to keep them in sync. I'm guessing there's a
better way to do that than jumping JACK around as you're experience seems to
indicate. Again, I'm new to this so I'm going to gather more information
from the web and you guys before I try to tackle something like clock drift.
I'm sure there are much more qualified people for this reading this email
thread.
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.
yeah, I was going to suggest you try. I went down that road trying to
code a jack-transport-sequencer. Alas most of the jack-clients won't
play fluid if you relocate the transport periodically to keep in sync.
agreed. and it may be easier to remain that way if
users want easy
control over MMC ID and a few other parameters related to MMC handling.
however the appeal of using some "parameter setting protocol" to set
this in a client that is otherwise invisible is fairly apparent.
I'll try to convert any settings that the user might want to change to
command line parameters for now, and we can rewrite it quite easily when/if
we want to change it to an in-server JACK client.
-- Alex
11:46 a.m.
"Alex Montgomery" <apmontgomery(a)gmail.com> writes:
http://repo.or.cz/w/jackctlmmc.git
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
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).
Yeah, if you could make it public via git that'd be very helpful. I
personally won't have time to code until the weekend unfortunately. 
9:37 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Davis wrote:
On Sun, 2008-11-09 at 15:21 +0000, Alex Montgomery
wrote:
I have been addressing similar issues in a different context:
Jack could provide multiple transports mechanisms, additional transports
can be derived from the master-transport or generated from external input.
However this would only be available to newer applications supporting
this jack-transport2 interface and leave it to the client application
to decide what to do (resample, vari-speed or pitch-shift..)
I don't know if the jack-protocol can be changed to accommodate multiple
transports without breaking binary compatibility. So
Implementation wise this could be done my distributing MTC over
JACK-MIDI (sync to the master-transport) and provide some wrapper
functions with libjack to query (parse received data) and control (send
command to time-source/jack-server) it.
Hello, I'm guessing from the research
I've done online and from the
lack of responses to my LAU message (
http://www.nabble.com/Slaving-jack-to-MMC-MTC-to20357929.html )
that JACK does not currently support slaving to external (or
internal?) devices via MMC/MTC. I'm a C/C++ developer by trade, so
I'm happy to get my hands dirty, but I wanted to know what other
work, if any, has been done on this front. I've been told that both
Rosegarden and Ardour can sync to MTC, but that they cannot then
drive JACK transport in that mode. Would it be difficult to move
this code over to JACK? Is there a reason this in't desirable?
JACK does not and will not support varispeed. Therefore slaving to
MTC is going to be pretty limited. MMC also sends some speed commands
that could not be supported by JACK. 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.
yeah, I was going to suggest you try. I went down that road trying to
code a jack-transport-sequencer. Alas most of the jack-clients won't
play fluid if you relocate the transport periodically to keep in sync.
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.
Ardour has build in support for MMC and MTC. I've used it quite a lot to
get old recordings from a Roland VS890 into gnu/Linux. Scrub-wheel,
Faders, start/stop BTNS can all be mapped via MIDI.
For syncing to jack-transport: I've used the other way around: generate
MTC from JACK and feed it into the 8-track. - MMC (start/stop buttons on
the VS890) can still control JACK-transport, but the scrub-wheel (uses
MTC and some realtime sysex) does not work this way.
so long,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkkZirEACgkQeVUk8U+VK0LmugCeOaEH9BqoXINnI419T/372KAE
HfAAnRYzhAbt1PQsQNDS4FnDMRP8kert
=RItW
-----END PGP SIGNATURE-----
5631
days inactive
5647
days old
linux-audio-dev@lists.linuxaudio.org
29 comments
8 participants
participants (8)
-
Alex Montgomery -
Jack O'Quin -
Nedko Arnaudov -
Paul Davis -
Ralf Mardorf -
Robin Gareus -
Rui Nuno Capela -
Stéphane Letz