[LAD] Jack MTC/MMC slaving

Robin Gareus robin at gareus.org
Tue Nov 11 13:37:56 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Davis wrote:
> 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.

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.

> 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-----



More information about the Linux-audio-dev mailing list