[LAD] midi beat clock
ralf.mardorf at alice-dsl.net
Sat Feb 20 19:56:15 UTC 2010
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
> 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.
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.
More information about the Linux-audio-dev