Synchronized clients and server

Questions
1

Hi guys,

me and some friends we want to play together with SC.
We made some experiments in creating a single server and using separate clients. We’ve also made some test with the Utopia Quark but unfortunately we are unable to reach our goal which is to share a common tempo clock in order to have a synchronization among us and our patterns and sounds.

Do you have some experience with the topic? How can we create a “networking” environment? Single Server and a series of clients? Maybe many synchronized server/clients instead? How to do that?
Can you help us better understand what the process to use?

Any help will be highly appreciated.
Thank you so much

2

The people involved in these developments (Scott Wilson, Alberto de Campo and Julian Rohrhuber) are mainly on the mailing list, maybe better to ask there.

1 Like
3

Thank you @dkmayer, I will try there!

4

I’ve spent too much time on this problem in the last few months.

You haven’t said which OS you’re on. That may make a difference.

If you can build SC’s “develop” branch from the source code, the best option is LinkClock, based on Ableton Link. https://github.com/supercollider/supercollider/blob/develop/HelpSource/Classes/LinkClock.schelp

Note that this has been merged into the development branch and is available for testing, but it is not in a current release download. You will have to build from source, or download a testing build from S3 (https://github.com/supercollider/supercollider/blob/develop/DEVELOPING.md#s3-build-hosting).

You don’t need Ableton Live to run it – Link looks for any other Link peers on the network, no matter which software. It works very, very well (but do be aware that meter changes are not currently working well).

Link is better because the messaging is in a separate thread, so it isn’t subject to interpreter contention. BeaconClock’s timing, and the timing of my own solution (https://github.com/jamshark70/ddwOSCSyncClocks) may be affected by a busy sclang interpreter. (However, ddwOSCSyncClocks can handle meter changes, with care.)

BeaconClock does not sync barlines. If you need barline sync, you’ll have to use LinkClock or DDWMaster/SlaveClocks.

While working on ddwOSCSyncClocks, I found some problems with incoming message timing that lead me to believe it’s basically impossible to solve this problem in sclang with a high degree of accuracy.

  • Mac <–> Mac is probably OK.

  • Windows <–> Windows: Very important to use a low latency audio driver (= ASIO). But even when we finally got all the students reliably using ASIO, one student’s machine seemed to delay sync messages even from hitting ctrl-return for a simple statement. We couldn’t get DDWMaster/SlaveClocks working to a usable degree. May be better with fewer machines, in a non-Chinese Windows installation.

  • Linux slave clock: Sync depends on comparing the DDWMasterClock’s seconds against the local DDWSlaveClock’s seconds (in all platforms). In Linux, I found a strange quantized relationship between the two clock values that was not reproduced when estimating the network round-trip time. So the offset between clocks is overestimated. The overestimate is the same for Windows master --> Linux slave and Mac master --> Linux slave – so it’s extremely unlikely to be a Windows problem. Clearly a unique “feature” in Linux. I added a bias parameter to correct this, and sync is fairly acceptable if you tune this by hand: DDWSlaveClock.new.bias_(0.04).measurementError_(0.03). But it’s annoying to tune by hand, and there is so much jitter in the offset measurement that sync tends to drift out and drift back, enough to be noticeable.

Again, none of this affects Link because it’s operating outside of sclang interpreter threads. So I would recommend Link if you can live without meter changes.

hjh

5

Oh, and if you’re using Link to sync with non-SC software (Live, Traktor, etc.), you need to set the clock’s latency to match server latency.

TempoClock.default = LinkClock.new.latency_(s.latency);

If all peers are SC, then latency_ doesn’t matter.

Also, I found that if I start SC shortly after waking my Linux machine from sleep, that the clock will “jump” at some point. This will break Link synchronization. I’ve reported a bug for this but there is no solution currently, except to wake up your computer at least 30 minutes before you need to start SC :sob:

hjh