1 Aug 2010 12:21
Re: Re: Re: Re: 3.5 plans
Scott Wilson <i <at> scottwilson.ca>
2010-08-01 10:21:09 GMT
2010-08-01 10:21:09 GMT
This is of course interesting, and was the problem br was really trying to address, IIRC. I think the broader point stands though, which is that in the common case of wanting to do sample accurate scheduling between client and server on the same machine, an AudioClock with the same semantics as SystemClock would be highly desirable. Tim's issue of intra-block control changes is also interesting, and relevant given audio-rate controls, but is a slightly different issue. Perhaps an alternative ar control UGen could deal with this, i.e. something that functioned a bit like OffsetOut, but with a variable delay. That would not be too hard I think, although such a UGen might have to have its own queue of events for multiple changes within a single block. (I'm afraid I don't quite understand the interpolation issue. If you're making intra-block changes, surely you're using an ar control, or?) S. On 31 Jul 2010, at 15:52, Sciss wrote: > to clarify: i'm just wondering if computer A counting sample-frames > from interface A, and computer B counting sample-frames from > interface B is working over longer periods without problems. > intuitively that should be the case, but who knows.... word-clock is > not time-code so it merely produces a pulse. if one interface has a > problem and re-syncs, the frame-counts in the "audio-clocks" might > have a discrepancy. > > i guess that other than trying it out one won't find out if this(Continue reading)
RSS Feed