So the question remains, any advice on syncing the client clock? Any SC functionality I'm overlooking or is this a fundamental I'll have to go into the scheduling C code to resolve?
I've been trying to write a version of Scheduler that can be externally adjusted. I've run into some difficulties when trying to get it to work
with 'drift' set to true, so I have left it for now. Anyway, it would be very good to have something like this. What it does is, each time it recieves an advance message, it schedules all events with a little bit of time ahead, but correctly between theadvances, based on the current tempo. This is done recursively so that event streams are rescheduled correctly. It also adds the methods elapsedBeats and schedAbs to be compatible with TempoClock.
I've attached the current version, maybe you find it useful somehow, and find a better name, maybe..
also attached is an unfinished helpfile for scheduler that I used as reference for testing.
(I will be wanting to keep algorithmic composition scheduling in the client) cheers N On 10 Nov 2004, at 23:40, James McCartney wrote:you'd still have to drive whatever clock on the client is buffering up the events.On Nov 10, 2004, at 1:47 PM, crucial felix wrote:keep it all on the server. its more liquid. like analog computers. get all your trigs and rhythms to be driven from ugens on the server. you can use the client to cue up event data in a buffer._______________________________________________ sc-dev mailing list sc-dev@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-dev_______________________________________________ sc-dev mailing list sc-dev@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-dev
Attachment:
%Scheduler2.sc
Description: application/applefile
Attachment:
Scheduler2.sc
Description: Binary data
Attachment:
%Scheduler.rtf
Description: application/applefile
Attachment:
Scheduler.rtf
Description: Binary data
-- .