[LAD] midi beat clock

[Ralf Mardorf]

Tim E. Real wrote:
> 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.

Hm, perhaps apps with audio tracks always should be master, to avoid 
resampling. If it would be possible to make the software clear, that 
somebody just is using a MIDI sequencer, without audio tracks, than 
there should be the possibility to be MTC slave too.
I'm not a coder, but I guess that the resampling issue won't be solved soon.