Re: [Sc-devel] [RFC] sample accurate scheduling

[blackrain <blackrain.sc@xxxxxxxxx>]

Since the lang does not have an idea of how much time it takes a
sample step for the synth, we give an offset in samples; the synth
will make the bundle effective based on that delta.

if we schedule a synth spawn for 1 sec in the future, scsynth will
execute the event in 1 second from the time of request but we have no
warranty that 1 second will be exactly 44100 samples from now (@
44.1kHz).

Scheduling a synth spawn 44100 samples from now will be 44100 samples from now.

we dont really need to know a sample count in the lang. latency will
allow us to play with delta samples times and always land exactly
where we want.

if there was the need, a PLL approach may work to obtain an interface
sample count but will probably result a bit expensive; depending of
course on the sync rate and the application.

in fact, we can still sort of calculate deltas in time (within bounds
as the examples I posted) but schedule in samples and we will be sure
the result will be there.

what I meant about the one sample impulse was in order to sync other
apps that may be connected thru digital audio lines to the synth -
this applies to other hosts too.
in that case the coreaudio clock for both interfaces (the same digital
clock) will advance at the same rate.
for a setup like that, all we need is a one sample impulse from the
foreign app to tell where play was engaged for example.

#sbndle (thinking a bit - still 8 bytes) will not break the current
standard implementation.
the server will know it is receiving a bundle that states a delta in samples.
we can use a Float64 to state deltas and be ale to handle subsample
accuracy instead of the usual 64 bit integer used to form time stamps.


x

On Nov 28, 2007 5:52 PM, Sciss <contact@xxxxxxxx> wrote:
> maybe you mean a kind of PLL (phase-locked loop) or servo-controlled-
> clock on the sclang side? so it queries in intervals the current
> scsynth clock and adjusts itself accordingly, so that s.latency for
> #sbundle's stay in a safe range?
>
> Am 29.11.2007 um 00:43 schrieb Sciss:
>
>
> > sounds interesting, but (maybe it's too late in the night) i don't
> > yet get how the #sbundle approach is working.
> >
> > Am 29.11.2007 um 00:32 schrieb blackrain:
> > [...]
> >> All that is needed like Jan states, is a one sample impulse and a
> >> responder to tell where the synth is.
> >
> > _______________________________________________
> > Sc-devel mailing list
> > Sc-devel@xxxxxxxxxxxxxxx
> > http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>