Re: IRC log re: rolling time
Alfons Adriaensen <fons.adriaensen <at> alcatel.be>
2004-12-01 14:15:24 GMT
On Wed, Dec 01, 2004 at 01:50:02AM +0100, Florian Schmidt wrote:
> On Tue, 30 Nov 2004 21:08:02 +0100
> Fons Adriaensen <fons.adriaensen <at> skynet.be> wrote:
> > This seems to be the inverse to a problem I was working on some time ago,
> > related to apps such as scsynth (SuperCollider's synthesizer engine) where
> > you have to map system time (from the OSC commands) to JACK frames.
> No, this is exactly the same problem (kinda sorta inaway ;)). See below.
> > Let's start with (2).
> > Suppose you have t_0, the system time corresponding to the first
> > frame of the current period. You can find t_n for frame n as
> > t0 + n / sample_rate. This will *not* always be monotonic when
> > used in different periods, for two reasons: the jitter on t_0, and
> > the error on the actual value of sample_rate (the latter is really
> > quite harmless in practice).
> > One solution is to calculate the time for the first frame in the
> > *next* cycle, t1, and use as t0 the value of t1 of the previous
> > cycle. Compute t_n as t0 + n * (t1 - t0) / period_size. This is
> > monotonic and continuous *by design*.
> Hmm, actually jackd doesn't need to map from frame n -> time t, but
> rather the other way around. The call in question is
This is still the same problem, provided some conditions are satisfied.
If you have a continuous and monotonic function n -> t then the inverse
function t -> n is also defined.