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