On Tue, 2006-11-07 at 14:29 +0100, Henning Thielemann wrote:
I also tried to create some music with the SuperCollider wrapper by Rohan Drape and the Haskore music package.
That's great, I have used the OSC part of the wrapper but not the rest, and haven't looked at Haskore yet but have some time tonight and tomorrow for that... I would like to hear more about how you got them to work together though.
However I had problems with accurate timing. How do you do the timing?
The way I see it there are two big issues - the first is drift and the second is latency. A drift error would be something like running at 120.2 bpm instead of 120 bpm. This isn't a problem until you try playing with other people. To fix it you have to avoid accumulating errors. I take a note of the time at the start of the program (or the last bpm change), then perform calculations based on what time it *should* be as an offset from that. The first time measurement you take is the only one you should keep. Latency I deal with by calculating everything a second or so ahead of time, and timestamping my OSC packets with times in the future. Then on the other side I have some scheduling stuff to trigger sounds at the right moment, for example in SuperCollider's sclang: response = { arg time, responder, message; if (message[1] == 'on', { SystemClock.sched(time - Date.getDate.rawSeconds, {Synth("noisebox", [\lgain, message[2] / 100, \rgain, message[3] / 100, \ts, message[4] / 100, \browndel, message[5] / 100, \filter, message[6], \envtype, message[7] ] ); nil; }; ); }); }; o = OSCresponder(nil, '/noise', response); o.add; However, as is quite obvious from that screencast, I haven't quite got around to timestamping Haskell OSC packets yet, I wanted to hear the latency. To timestamp a packet you just have to put it in a timestamped bundle though. I hope that's useful, if not let me know more about your timing problems, maybe I can still help. alex