File: LinkClock.schelp

package info (click to toggle)
supercollider 1%3A3.13.0%2Brepack-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 80,292 kB
  • sloc: cpp: 476,363; lisp: 84,680; ansic: 77,685; sh: 25,509; python: 7,909; makefile: 3,440; perl: 1,964; javascript: 974; xml: 826; java: 677; yacc: 314; lex: 175; objc: 152; ruby: 136
file content (286 lines) | stat: -rw-r--r-- 12,498 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
class::LinkClock
categories::Scheduling>Clocks
summary::Scheduler synchronized with Ableton Link
related::Classes/TempoClock

Description::

LinkClock is a link::Classes/TempoClock:: based on link::https://www.ableton.com/en/link/##Ableton Link::, a protocol
that synchronizes phase (beat-within-bar) and tempo over a local network.

Subsection:: Link behavior

Link attempts, as much as possible, to allow applications to move in their own time while synchronizing:

list::
## Tempo: Any application can change the tempo at any time.
## Beat: Integer beats should sound at the same time in all applications.
## Phase (analogous to SuperCollider's link::Classes/TempoClock#-beatInBar::): A downbeat in one peer should correspond to a downbeat in other peers.
::

Link does not synchronize exact beat numbers. Two SuperCollider peers joining the same Link session, in 4/4 time, may be respectively at beats 4 and 16 (which are both barlines), but they should not be at beats 4.0 and 19.0.

Many Link-enabled applications (DAWs) can start and stop the entire timeline. SuperCollider clocks do not stop. A DAW, when starting to play, should lock into SuperCollider's phase within the bar. You can register functions to respond to other peers starting or stopping. (SuperCollider does not know which other peer started or stopped.)

Subsection:: Latency

Link coordinates the emphasis::sounding time:: of given beats.

All audio applications must prepare events, and audio processing, in advance, so that the signal hits the audio interface at the right time. SuperCollider uses OSC timestamps for this purpose, calculating timestamps from the current time in seconds + a teletype::latency:: offset.

To coordinate with other applications, then, the code::LinkClock:: must run earlier than the desired sounding time, by the same fixed offset. That is, it should have the same (positive) latency offset as the server:

code::
t = LinkClock.new.latency_(Server.default.latency);
::

Server messages should then be sent with the same amount of latency. Events generated by patterns automatically apply the server object's latency. For other messages, use link::Classes/Server#-makeBundle::.

With a positive latency, if you examine code::t.beats::, it will appear to be later than the beats shown in other applications. This is normal. The clock in SuperCollider must run early for the events to sound on time.

(Because the clock and server have separate latency settings, it is possible to adjust timing relative to other applications. If you find, for instance, that SuperCollider is sounding slightly late, you can increase the LinkClock's latency slightly, moving the clock earlier, without affecting messaging latency. Ideally, this should not be necessary, but inter-application coordination can be fiddly.)

This does have an impact on tempo changes. SuperCollider receives tempo changes from other peers only after they are sent, which is probably slightly late for our clock. In practice, it means that events falling within the latency gap may be slightly out of sync, but sync should recover very quickly. (So, Link is not ideal for music involving frequent tempo or meter changes.)

Subsection:: beatsPerBar and quantum

For every moment in time, Ableton Link knows the beat, time in seconds, and emphasis::phase::. Phase is measured relative to a emphasis::quantum::. Link peers sharing the same quantum will synchronize barlines.

For instance, assume quantum = 4. Peer A is currently at beat 33. Peer B joins the network. Peer A's last barline was beat 32, so phase = 1. Peer B's beat counter should arrange to have the same phase: in practice, it will start with -3.

table::
## strong::Phase:: || strong::Peer A beats:: || strong::Peer B beats:: || Notes
## 0 || 32 || -- ||
## 1 || 33 || -3 || Link calculates -3 for B
## 2 || 34 || -2 ||
## 3 || 35 || -1 ||
## 0 || 36 || 0 || Barline (synced)
::

If you change the quantum, Link does not guarantee that beats will keep the same duration. Beats may be shorter or longer, to try to preserve phase sync.

Therefore, you should emphasis::not:: change the quantum in the middle of a performance. Ableton recommends to set the quantum just before beginning. Then, you can change SuperCollider's code::beatsPerBar:: as needed, without changing the quantum, so that Link's phase reference remains consistent.

SuperCollider peers may optionally synchronize barlines and all meter changes by using link::Classes/LinkClock#-enableMeterSync::. This is independent of Link's quantum, and is safe to use mid-performance. See link::Classes/MeterSync::.

Subsection:: Notifications

A LinkClock's state may be changed by other connected Link peers. LinkClock uses dependant notifications to relay the new state to other interested objects.

table::
## strong::Notification:: || strong::Event::
## code::\tempo:: || Tempo changed
## code::\meter:: || The clock's code::beatsPerBar:: changed
## code::\linkStart:: || An external peer started playback
## code::\linkStop:: || An external peer stopped playback
## code::\numPeers:: || The number of connected peers changed
## code::\resynced:: || After link::#-enableMeterSync::, a code::\resynced:: notification is sent whenever a link::Classes/MeterSync#-resyncMeter:: call finishes successfully. One Boolean argument is passed: code::true:: if other SuperCollider peers were found, code::false:: if not.
::

(Note that Link does not synchronize meter across peers; this notification is inherited from TempoClock. link::Classes/LinkClock#-isSyncingMeter:: is a SuperCollider-specific way to synchronize meter; it is not part of the Link protocol.)

The most convenient way to register to receive a notification is link::Classes/SimpleController::. See the examples below.

Classmethods::

method::new
Creates a new instance of LinkClock.

argument:: tempo
The initial link::#-tempo#tempo::. Defaults to code::1::.

argument:: beats
The time in beats, corresponding to the reference time. Default to code::0::.

argument:: seconds
The reference time in seconds. See link::Classes/TempoClock#*new::.

argument:: queueSize
The storage size of the scheduling queue. See link::Classes/TempoClock#*new::.

discussion::
If an existing Link session is found on the local network, the object connects
to it and use its properties: the code::tempo:: argument is discarded in favor
of the session tempo, and the code::beat:: argument will be adjusted to ensure
proper beat and phase synchronization across all peers.
If SuperCollider is the first to join, a new Link session is locally
created and initialized with the constructor arguments.

method::newFromTempoClock
Creates a new instance of LinkClock derived from a link::Classes/TempoClock::.

argument::clock
The link::Classes/TempoClock:: used to create the LinkClock.

discussion::
The LinkClock link::#-tempo#tempo::, link::#-beats#beats::,
link::#-seconds#seconds:: and link::#-beatsPerBar#beatsPerBar:: values are
set to those of the TempoClock. The TempoClock is then stopped and all of its
tasks are rescheduled by the newly created LinkClock, so that they are now
synchronized with the Link session.

Instancemethods::

private:: prInitFromTempoClock, prSetQuantum, prStart, prTempoChanged, prStartStopSync, prNumPeersChanged, setMeterAtBeat, setTempoAtBeat, setTempoAtSec

method:: latency
Gets or sets the number of seconds of OSC messaging latency for which the code::LinkClock:: should account. In general, this should be set to match the server object's latency.

argument:: lat
A Float.

method:: tempo
Sets or gets the current session tempo at the current logical
time. Note that the tempo may be changed at any time by another peer;
the LinkClock broadcasts a code::\tempo:: notification in this case
(see link::Classes/LinkClock#Notifications::).

method:: beats
Sets or gets the current logical time in beats. If you are trying to set
the beats, Link may adjust your given value to maintain sync with other peers.

method:: numPeers
Gets the number of peers connected to the current Link session. When
peers join or leave the session, the LinkClock broadcasts a
code::\numPeers:: notification (see
link::Classes/LinkClock#Notifications::).

method:: quantum
Gets or sets Link's internal quantum (see above, link::#beatsPerBar and quantum::). Normally this should be done at the beginning of a performance, or not at all. It is risky to change quantum during a performance. Changing meter locally is the same as in TempoClock: link::Classes/TempoClock#-beatsPerBar::.

argument:: quantum
An Integer or Float.

method:: enableMeterSync
Activates SuperCollider-barline sync by creating a link::Classes/MeterSync:: object internally. (If already enabled, no new object will be created.)

argument:: id
Optional: An integer ID, uniquely identifying this instance. If not provided, one will be chosen randomly.

argument:: ports
Optional: An array of port numbers, to which barline-sync messages will be sent.

returns:: The LinkClock instance (to support chaining configuration methods, e.g. code::l = LinkClock.new.latency_(s.latency).enableMeterSync::, in which case you want code::l:: to be the clock object). To get access to the MeterSync object, use link::#-getMeterSync::.

method:: disableMeterSync
Remove all barline-sync objects.

method:: isSyncingMeter
returns:: A Boolean, code::true:: if barline sync is active, code::false:: if not. (If you create the barline sync object independently, this answer is likely to be incorrect.)

method:: getMeterSync
returns:: The MeterSync object previously created by link::#-enableMeterSync::.

note:: It is possible, though redundant and not recommended, to create multiple barline-sync objects by doing code::clock.enableMeterSync:: and code::m = SCClockMeterSync(clock)::. code::getMeterSync:: has access emphasis::only:: to the object created by code::clock.enableMeterSync::. Therefore, it is recommended to use code::clock.enableMeterSync:: in all cases. ::

Examples::

code::
(
s.waitForBoot({
	SynthDef(\click, { |freq=400, amp=0.2|
		var sig = SinOsc.ar(freq, 0.5pi) *
			Env.perc(0.001,0.06).ar(Done.freeSelf, levelScale: amp);
		OffsetOut.ar(0, sig.dup)
	}).add;
});
)

// create a synchronized clock
l = LinkClock(1).latency_(Server.default.latency);

// GUI to watch status
(
var win = Window("LinkClock", Rect(200, 200, 500, 100)).front,
peersBox, tempoBox, barsBox, beatsBox,
font = Font.default.copy.size_(32),
boldFont = font.boldVariant,
controller, task;

win.layout = HLayout(
	StaticText().font_(font).string_("Peers:"),
	peersBox = NumberBox().font_(boldFont).align_(\center).fixedWidth_(80),
	StaticText().font_(font).string_("Tempo:"),
	tempoBox = NumberBox().font_(boldFont).align_(\center).fixedWidth_(120),
	StaticText().font_(font).string_("Now:"),
	barsBox = NumberBox().font_(boldFont).align_(\center).fixedWidth_(80),
	beatsBox = NumberBox().font_(boldFont).align_(\center).fixedWidth_(80)
);

[peersBox, barsBox, beatsBox].do { |view| view.enabled_(false) };

tempoBox.action = { |view| l.tempo = view.value / 60 };
tempoBox.value = l.tempo * 60;
peersBox.value = l.numPeers;

task = Routine {
	var bars, beats;
	loop {
		bars = l.bar;
		beats = l.beatInBar;
		{
			barsBox.value = bars;
			beatsBox.value = beats;
		}.defer(l.latency);
		1.0.wait;
	}
}.play(l, quant: 1);

controller = SimpleController(l)
.put(\tempo, {
	defer { tempoBox.value = l.tempo * 60 }
})
.put(\numPeers, {
	defer { peersBox.value = l.numPeers }
})
.put(\stop, { defer { win.close } });

win.onClose = { task.stop; controller.remove };
)

// now launch a program using Ableton Link to test synchronization

// patterns automatically apply server latency,
// so this should be in sync
p = Pbind(\instrument, \click, \freq, Pseq([900, Pn(400,3)], inf)).play(l, quant:4);

// In Tasks, you should handle latency yourself:
(
r = Task {
	loop {
		s.makeBundle(s.latency, {
			Synth(\click, [freq: exprand(500, 1200)])
		});
		1.wait;
	}
}.play(l, quant: 4);
)

// changing the tempo in another application should affect tempo in SC
// changing the tempo in SC should affect every connected application
l.tempo = 90/60;

// start/stop notifications
// the remote peer should enable start/stop sync
(
q = nil;
c = SimpleController(l)
.put(\linkStart, {
	if(q.isNil) {
		q = Pbind(
			\degree, Pn(Pseries(0, 1, 8), inf),
			\dur, 0.25
		).play(l, quant: -1);
	}
})
.put(\linkStop, {
	q.stop;
	q = nil;
})
.put(\stop, { c.remove });  // clean up if clock stops
)

p.stop;
r.stop;
l.stop;
::