LinkClock.newFromTempoClock best practice?

Questions
1

Hi list,

Is this the correct or best way how to put a LinkClock in place of an
existing and running TempoClock? Is it normal to get some slight timing
hickups (late 0.039317007 messages)?

~clock = TempoClock(130/60).permanent_(true);

~oneChord = Pbind(\degree, [0,3], \legato, 0.1).play(~clock, quant: 4);

~clock = LinkClock.newFromTempoClock(~clock).latency_(Server.default.latency).permanent_(true);
~clock // now gives: a LinkClock

~anotherChord = Pbind(\degree, [5,7], \legato, 0.1).play(~clock, quant: 4);

(
~oneChord.stop;
~anotherChord.stop;
~clock.stop;
)

thanks!
Peter

2

One bit of fine print that I didn’t discover until quite a bit later is that truly accurate timing requires adjusting by the hardware buffer size here.

This gets a little weird because 1/ the client doesn’t have access to the hardware buffer size, and 2/ I thought the latency adjustment should be subtraction, but when I tested just now, I needed to add to the latency.

If SC sounds late, then add to the clock’s latency.

Sorry that I can’t be more specific. In practice, you just have to fudge it until it works.

When you start a LinkClock, it doesn’t know what time it is – so, the first portion of a beat, up to a beat, will report an incorrect time value. This quickly gets adjusted to match the Ableton Link session.

I think it’s a bad idea to have anything trying to maintain correct timing during this adjustment period. So, I wouldn’t use newFromTempoClock in any sort of production situation.

If hiccups are occurring after that point, then I’m not sure. I haven’t seen that behavior, but I tend to run with the default 0.2 seconds latency. If you’re pushing latency down toward its lower limit on your system, then Link’s timing adjustments to match other peers might occasionally not have enough of a cushion.

FWIW I’ve become somewhat disenchanted with LinkClock. It’s great when it works, but I’ve had too many times when it either failed to connect, or it connected but there was some timing discrepancy, or it connected but then disconnected after some time.

hjh

1 Like
3

James,

thanks! I read about your findings regarding the additional buffer size
latency already in another post. Thanks for the additional details here!

Do you know if LinkClock automatically reconnects after network
drop-outs? Is there any better known alternative?

best, P

4

AFAIK it’s supposed to poll the network continuously looking for peers, so it “should” recover from dropouts. This may or may not be consistent though.

I think there’s unlikely to be a protocol with widespread compatibility like this one, though I could be just unaware of it.

hjh

5

Thanks James,

I am glad LinkClock exists in the first hand place.
I am currently trying to use multiple sclang clients with a single
server. Since Patterns run on the language side I wonder if there is
another Clock mechanism that can sync these several languages apart from
LinkClock. Compatibility with other software and the ableton protocol is
not required. Has there ever been something like a ServerClock to sync
multiple language clients?

best, P

6

Scott Wilson had something called BeaconClock, but I forget which quark it’s in.

I tried my hand at it a few years ago, but it never worked exactly right. I think the problem is that I used direct messages by IP to estimate the message transport time, but broadcast messages for sync, and (it seems) broadcast messages are slower. It could be manually tweaked though. It follows the model of a single leader clock, with any number of followers, different from the LinkClock distributed model.

That’s the ddwOSCSyncClocks quark – you could try to edit the code. I can’t do much with testing it on multiple machines for the moment, until March.

hjh