Re: [LAD] Jack MTC/MMC slaving

From: Robin Gareus <robin@email-addr-hidden>
Date: Tue Nov 11 2008 - 15:37:56 EET

-----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-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Nov 11 16:15:04 2008

This archive was generated by hypermail 2.1.8 : Tue Nov 11 2008 - 16:15:04 EET