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

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.

> 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