Quick question, can the sonic pi be clocked from an external source or synced to external clock? And how accurate is the scheduler? (ie is it self correcting to compensate for drift or does it hold steady?)
thanks!
Hi Iain,
the scheduler is very accurate and absolutely accounts for drift. For some technical background see: https://www.doc.ic.ac.uk/~dorchard/publ/farm14-sonicpi.pdf
However, syncing to an external source isn’t Sonic Pi’s strong point at the moment, although it’s something I’m working on improving. The best you can currently do is to use_real_time in all your threads, and sync on well-timed external OSC/MIDI messages.
Hope this helps 
Oh the paper looks fascinating, thanks! I’ve done some clock coding of my own getting in the past getting a csound built sequencer engine to lock up nicely with other tools, and it’s a non-trivial task. 
I realize that the main thrust of SonicPi is to be an accessible all-in-one live coding environment, but I’m curious if people are using it along side other systems, hence the clocking question. IE has anyone got it playing nicely with Ableton Live and Max4Live? I’ve been looking recently for a platform on which to build something that gives people a way to interact live with an ongoing performance, where said performance is likely to involved live musicians playing commercial tools mixed with things hacked up in Max/MSP and SuperCollider, so am trying to figure out if SonicPi, or some possible variant of it, could be the basis for that. So that’s the reasons for my questions. I appreciate the responses, thanks
Without diving into the paper, another question: Does the scheduler self-correct to the point that a tempo will be accurate to the nearest sample over the long haul? IE could one lock Sonic-Pi pretty easily to something else, IFF said something else were also self correcting and running off the same sample clock source (ie. sound card clock)?
I did something similar with CSound along time ago, and we could get acceptable sync that way without having to have both systems running off one time signal, and it was certainly good enough for at least an hour long performance.
I’m not quite sure what you mean by sample in your question. Unfortunately it’s a ridiculously overused word in this context 
Could you possibly expand?
Also, for the record, Sonic Pi uses the system clock to avoid drift which is the same as the SuperCollider audio server which ultimately generates the audio and the Erlang MIDI/OSC scheduler which generates external events.
Thanks Sam. In my case I mean the Csound clock we ran counted audio frames rendered and corrected the tick rate off that. I’ve played with SC a bit (and really like it!) but not dug into how it does its timing. Thanks for the information, looking forward to checking it out further.
If I recall correctly (it was a while ago…) that means the audio clock tick came from whatever audio driver you chose for the Csound engine. (cobwebs, cobwebs, this was like 10 years ago)