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

[blackrain <blackrain.sc@xxxxxxxxx>]

It would be great to listen to what Mr McCartney thinks.
Maybe he already has something in mind.

x

On Nov 28, 2007 7:31 PM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:
> Might be worth running this by James McCartney if he's not already
> following this thread. I believe he mentioned this issue in his talk
> in the Hague, and the general desirability of scheduling against a
> variety of different clocks as needed.
>
> S.
>
>
> On 29 Nov 2007, at 00:26, blackrain wrote:
>
> > 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
> >>
> > _______________________________________________
> > 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
>