DDWLeadClock
Extension
ExtensionDescription
With DDWFollowClock, a minimalistic lead-follower approach to synchronizing multiple SuperCollider language instances over a local network. (For technical details, see DDWFollowClock: How it works.)
The local network should allow broadcast messages (IP address "255.255.255.255"). If your system has a firewall, make sure SuperCollider's ports (57120, 57110) are open for UDP traffic.
Currently the lead clock sends only to sclang's default port, 57120. You may override DDWLeadClock: -addr to change this behavior.
Both DDWLeadClock and DDWFollowClock inherit from TempoClock. After creating the clocks, their operation is identical to that of TempoClock. Basic TempoClock features are not documented here; consult the TempoClock help file for details.
Usage
Normal usage is:
- One lead clock, providing a global tempo for the entire network.
- Any number of follower clocks, on other machines.
For this use case, the procedure is: 1. Create the lead clock. 2. On the other machines, create one follower clock instance per machine. The followers should automatically detect sync messages coming from the lead, and synchronize beats and tempo within a second or two.
It is also possible to run multiple lead clocks, at different tempi. Each lead clock should have a different ID. (If you don't provide one, an ID will be chosen from UniqueID, but if you need multiple tempi, it is highly recommended to specify an ID as a number or Symbol.) Then, follower clocks can be created for specific IDs. (Note: This scenario is not extensively tested yet.)
Class Methods
.new
Create a lead clock instance. It will begin broadcasting immediately.
Arguments:
| tempo |
As in TempoClock, the tempo in beats per second. |
| beats |
As in TempoClock, the beat count to initialize the clock. Optional. |
| seconds |
As in TempoClock, the seconds count to initialize the clock. Optional. |
| queueSize |
As in TempoClock, the size of the scheduler array. |
| id |
A number or symbol identifying this lead clock to other machines. If you only need one lead, this is optional; an ID will be chosen for you, and follower clocks will pick up the first ID they receive. |
Returns:
The new clock instance.
Instance Methods
.id
The clock's ID.
.latency
The latency value used for sync messages. Normally you should not need to change this.
Returns:
A numeric latency value.
.addr
The NetAddr to which sync messages are sent. If you choose to change it, please use the broadcast IP address "255.255.255.255". By default, addr is NetAddr("255.255.255.255", 57120). You may override this, for example, with NMLNetAddrMP from the Utopia quark to broadcast sync messages to multiple ports.
Returns:
A NetAddr.
Examples
You can run all of this example on one machine in one sclang instance, or run the sections on different machines as indicated.
Acknowledgment
Credit is due to Scott Wilson, for one critical idea borrowed from his BeaconClock class (in the Utopia quark). A possible issue with clock sync is processor contention: integer beats tend to be busy. BeaconClock and DDWLeadClock both broadcast sync messages at randomized intervals, so that sync messages will almost certainly be sent "in between" musical events, avoiding messaging delays.
link::ddwOSCSyncClocks/Classes/DDWLeadClock::