20 Feb
2010
20 Feb
'10
4:07 p.m.
On February 20, 2010 02:56:15 pm you wrote:
Tim E. Real wrote:
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.
On February 20, 2010 01:19:52 pm Paul Davis
wrote:
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. On Sat, Feb 20, 2010 at 11:03 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
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. 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.