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

[blackrain <blackrain.sc@xxxxxxxxx>]

Hello James,
If I understand the idea correctly, we can create a TempoClock; Update
its tempo on /status based on a hardware sample rate / nominal sample
rate ratio. For an anchor, a) the server's block count could be added
to /status messages b) use a dedicated message - maybe at a higher
rate? c) have an absolute samples clock UGen that can be polled (check
my recent post on this please).

The problem I see with this approach is that hardware sample rate
instant value will not be there by the time /status messages get
processed.
We will be still guessing/drifting but again, I may have not gotten
the whole picture...

x


On Dec 2, 2007 12:13 AM, James McCartney <asynth@xxxxxxxxx> wrote:
> On 12/1/07, James McCartney <asynth@xxxxxxxxx> wrote:
> > The issue of hardware clock drift was certainly understood when
> > deciding to use OSC time stamps. SC3's goal was not sample accurate
> > scheduling, but accurate distributed scheduling based on a shared
> > clock (NTP time). So even on servers running at different sample
> > rates, you get simultaneous events. An anchor point and rate scalar
> > can be computed between the actual hardware rate and OSC time on each
> > server and broadcast to interested clients.
>
> To be more clear this should read:
>
> In order to support sample accurate scheduling however, an anchor
> point and rate scalar  can be computed between the actual hardware
> rate and OSC time on each server and broadcast to interested clients.
>
>
> --
> --- james mccartney
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>