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 > >> > >> <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
