[LAD] midi beat clock
Tim E. Real
termtech at rogers.com
Sat Feb 20 19:38:19 UTC 2010
On February 20, 2010 01:19:52 pm Paul Davis wrote:
> On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
> <ralf.mardorf at alice-dsl.net> wrote:
> > If Linux apps would use JACK transport the coders only would have to
> > take care to handle this. Just having on app doing sync among JACK and
> > eternal MIDI would reduce the risk of trouble. Btw. MTC should be part
> > of such an app too ... I didn't read the whole thread, perhaps this was
> > mentioned before.
> this isn't true.
> one of the most deliberate and conspicuous design decisions of the
> JACK transport API is that there is no support for varispeed.
> sync requires knowing two things: where we are, and how fast we are
> going. JACK transport has only 2 answers the the second question
> (stopped, rolling). this isn't adequate to fully capture the notion of
MTC: Maybe veering OT a bit but if we could just touch on this for a moment.
Was going to ask about this anyway, as we had talked about it a bit.
I thought "it's too bad we can't adjust Jack's sample rate on the fly"
thus allowing Jack to behave like a Voltage Controlled Oscillator in a PLL,
syncing to MTC frame.
I was thinking the VCO 'control' signal would come from a client.
Else Jack itself would have to support MTC.
But raises the question - which Jack back-ends allow dynamic sample rate
changes? And with a finite resolution small enough?
I concluded that the best way for me to sync Jack audio with an
external MTC is with app-side audio time stretchers.
More information about the Linux-audio-dev