This semester, I struggled with syncing multiple sclang instances on several computers across the network. I ended up being unsatisfied with available options, so, in the break between classes, I wrote my own.
Available sync methods:
-
BeaconClock (Utopia quark).
- Pro: Distributed model (all machines are “peers” and mutually agree on sync; in theory, any machine can drop off the network and rejoin, without the others being affected).
- Con: There was a bug in it that might have been fixed, but I haven’t had a chance to test the fix. AFAICS, its handling of network jitter is relatively naïve (assumes near-instantaneous transmission of messages). Sclang only.
-
DDWMasterClock + DDWSlaveClock (mine, new).
- Pro: All slave clocks match the master’s tempo, beats, beatsPerBar, baseBarBeat (meter) etc. During testing, I found I couldn’t assume instantaneous network transmission so I added Kalman filters to stabilize. Multiple, independent timebases are supported by giving IDs to clocks; on the master machine, you could run as many clocks as needed, with independent tempi that you’re certain you started at the same time. (I’m pretty sure BeaconClock’s distributed approach would make that extremely difficult.)
- Con: In the master/slave model, slaves could drop out and rejoin, but if the master fails, sync would be lost and it may be impossible to recover. Sclang only. It’s new and hasn’t had a lot of testing.
-
LinkClock (Ableton Link)
- Pro: Extremely robust handling of network timing (probably better than mine). Interfaces with any Ableton Link capable software.
- Con: Well, the big negative is that it isn’t finished yet. You would have to build a specific branch yourself. Sclang is probably not handling server messaging latency correctly yet for LinkClock. That’s under discussion at github. (Also, for a bunch of reasons, my needs include backward compatibility with 3.9, and that will be impossible for Ableton Link support.)
So… with that, I’m throwing my classes out there and inviting people to test them – especially people who have access to 2 or 3 computers on a LAN.
If you have git, you can get it by:
Quarks.install("https://github.com/jamshark70/ddwOSCSyncClocks.git")
Otherwise visit https://github.com/jamshark70/ddwOSCSyncClocks.
Basic usage is simple:
// On the master machine (substitute your tempo):
TempoClock.default = DDWMasterClock(myTempo);
// On the slave machines:
TempoClock.default = DDWSlaveClock.new;
Wait a couple of seconds, and the slave clock should jump to the master’s beat count. Then you can use both clocks as normal TempoClocks (except, the slaves can’t change tempo or meter – they have to follow the master clock).
Here’s a short audio clip, where the drums are coming from one sclang instance, and hi-hats and bass from a different sclang instance. They are on the same machine, but for testing purposes, I’m adding random timing jitter between 50 and 125 ms to the calculations, to simulate really horrible network performance, and the result sounds musically acceptable to me.
So I’m cautiously optimistic about this approach (though I really need to take it into my media lab at school and run it on half a dozen computers at once).
hjh