Re: [LAD] midi beat clock

On February 20, 2010 02:56:15 pm you wrote:
> 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@email-addr-hidden-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.
I also concluded that with MTC, since it is purely frame-based, it is up to
 the slave apps to translate that into BBT for midi engines.
Thus *requiring* local tempo/signature maps be in use.
Well, that is until we get that shared tempo map thing happening...

Stretchers are playing a very important role in my designs now.
Even just using tempo maps requires them with audio tracks, if the
 user wants to change a tempo AFTER recording an audio track.

Tim.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Feb 21 00:15:05 2010