[LAD] midi beat clock

[Tim E. Real]

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

Tim.