MIDISyncClock | SuperCollider 3.13.0 Help

Description

A substitute clock that follows MIDI clock messages from an external source, with some caveats.

NOTE: If possible, for MIDI clock sync, it is recommended to use SuperCollider as the clock source, so that you can control for server latency. (See MIDIOut: -latency -- MIDI messages going out from SuperCollider can be delayed by an amount matching the server's latency. This will ensure better sync than is possible by responding to an external source.)

If it is absolutely necessary to follow an external source, use this class.

Usage

Recommended procedure:

Be sure the clock source is not running.
In SuperCollider (receiving machine), initialize MIDIClient (MIDIClient: *init).
MIDIIn.connectAll. (I believe sysrt messages are received from any available port. If SC fails to respond, you might try connecting incoming port 0 to the device from which clock messages are coming: MIDIIn: *connect. In theory this should be unnecessary).
Initialize MIDISyncClock (MIDISyncClock: *init).
Start the clock source.
(Optional) Set MIDISyncClock: *schedOffset

The clock source should begin by sending a MIDI clock "start" message, resetting MIDISyncClock to beat 0. This is essential for beat sync. If you start the clock source first, and then initialize MIDISyncClock, the beats will probably not line up.

NOTE: MIDI clock "tick" messages do not provide any information about the position within the bar. The only way to be sure beats are synchronized is to initialize MIDISyncClock first, and then start the external source. This is a limitation in the MIDI protocol; there is nothing I can do about that.

Latency compensation

A manual scheduling offset may be given by hand.MIDISyncClock.schedOffset = -8;

In theory, the number of ticks to offset should be server_latency.neg * tempo * ticksPerBeat (where the last is usually 24). But, you may need to add some amount for audio driver latency (making the offset closer to 0). Because audio driver latency is unknown within the language client, it is up to you to tune the scheduling offset by hand. (Important: Offset should be negative!)

Limitation: The offset depends on tempo. So, if the clock source's tempo changes, the offset will be incorrect. It is difficult to compensate for this (and, to be honest, I'm not that interested in the problem). So, for now, if you expect tempo changes, it's advised not to use schedOffset; instead, set server latency to nil and the soundcard to the smallest possible buffer size, to try to reduce the impact of latency.

Limitations

The MIDI standard specifies 24 clock pulses per quarter note. MIDISyncClock does not attempt to interpolate scheduling times between pulses. Any events scheduled for a time in between pulses will fire on exactly the next pulse. Subdivisions of the beat other than duple and triple will therefore be slightly inexact (but, at 60 bpm, one pulse is about 42 ms, so any timing deviation will be hard to detect by ear).
The tempo measurement is slightly unstable, generally within a percentage point. This is a necessary consequence of reacting to messages whose timing is not 100% accurate.
Because the tempo measurement is unstable, MIDISyncClock cannot properly support TempoClock: -secs2beats. Instead, it returns current beats. This is not a problem for normal usage (playing Tasks and patterns). It may be a problem if you need to coordinate the MIDI clock with other clocks at different tempi.

Class Methods

Most of the methods of MIDISyncClock attempt compatibility with TempoClock. Consult TempoClock documentation for details on scheduling events and managing metrical position.

One exception is TempoClock: -tempo. MIDISyncClock derives its tempo from the external source; for obvious reasons, then, you cannot override the tempo by tempo_.

.init

Initialize MIDISyncClock's internal state. Must be called before starting the external clock source.

.schedOffset

Change the MIDI clock's scheduling offset.

Arguments:

newOffset	An number of ticks by which to offset (recommended to be an integer). A negative offset shifts scheduling earlier. This is the normal case for latency compensation.
reschedule	A Boolean indicating whether or not to reschedule items currently on the clock to account for the new scheduling offset. The default is true, so that you should hear the result of the offset immediately.

Examples

This demonstration will generate MIDI clock messages within SuperCollider.// Initialize the MIDI objects first MIDIClient.init; // step 2 above MIDIIn.connectAll; // step 3 MIDISyncClock.init; // step 4 // This next block runs a clock source in SC. // If you have an external clock source, use it AND SKIP THIS PART. // Otherwise, see MIDIOut documentation for details on connecting // SC MIDIOut to... itself :D ( // You might need to change the string here: IAC MIDI on Mac? d = MIDIClient.destinations.detect({ |ep| ep.device == "SuperCollider" }); m = MIDIOut.newByName(d.device, d.name); Tdef(\mc).quant = -1; Tdef(\mc, { var tick = 1/24; m.start; loop { m.midiClock; tick.wait; }; }).play; ShutDown.add { Tdef(\mc).stop }; ) // Use the clock // For an external source, set latency as low as possible s.latency = 0.03; // quant: -1 = start on a barline ( p = Pbind( \degree, Pseq([ -7, Pwhite(0, 7, 15) ], inf), \dur, 0.25, \amp, Pseq([0.5, Pn(0.1, 15)], inf) ).play(MIDISyncClock, quant: -1); ) p.stop;

helpfile source: HelpSource/Classes/MIDISyncClock.schelp
link::ddwMIDI/Classes/MIDISyncClock::

MIDISyncClockExtension