Some notes;<br><br>A remark was made about the importance of timing in dance music. I don&#39;t think sample accuracy is mandatory there, at least not for sequencing. Even a well implemented MIDI clock (Atari,old MPC&#39;s) will service there beyond what most people need and MIDI is slooooow. Bad MIDI clocks may be a issue and require work-arounds. If you can get it down to the MS range for jitter and latency you are set, I&#39;dsay.<br>
<br>Some attempts have been made to sync to sample accuracy over OSC, for example some wavefield synthesis systems that use a cluster of computers because more channels than a single one can take are needed (one system uses about 800 channels so that&#39;s a real issue). I think this works with time-stamped messages but to get hose to work you need a synced clock. That clock will likely be synced to a networked soure as well so the benchmark for that already has jitter. We could ask Marije Ballman for what she uses there but I&#39;d suspect severe degrees ove Linux tweaking might be involved and some of it might be spoeciffic to SC.<br>
<br>Most modern mainstream OS&#39;s aren&#39;t even realtime so unless you go Linux with a RT kernal no guarantees can be made at all about when messages will arrive and I&#39;m not even sure to what degree a RT kernal will affect TCP-ip message processing. On top of that there is the inherent jitter caused by ChucK only processing such info once per block/buffer and at current CPU speeds and soundcard stats I don&#39;t think you&#39;ll be running ChucK with a block of 1sample.<br>
<br>In short; I&#39;d abandon this as a goal and shoot for a situation where I didn&#39;t notice any latency anymore, then simply go with that.<br><br>For music what you hear and don&#39;t hear is a lot more important than arbitary yet absolute standards, IMHO.<br>
<br>Yours,<br>kas.<br>