Too many "late 0.xxxxxxxxx" messages

Questions
1

Dear users,

sclang often posts too many “late 0.xxxxxxxxx” messages when evaluating the following code. Is the code not ideally constructed?

(
var tune, pitches, rhythms, tempo, rand;
tune = [
	[[0, 4], 2, 4, 0]!2,
	[[4, 4], 5, [7, 2]]!2,
	[[7, 8], 9, 7, 5, [4, 4], 0]!2,
	[[0, 4], -5, [0, 2]]!2
].flatten(2);

pitches = tune.size.collect{ |i| tune[i].asArray[0] };

rhythms = {
	var number;
	tune.size.collect{ |i| 
		var thisItem;
		thisItem = tune[i].asArray[1];
		number = if (thisItem != nil) { thisItem } { number };
		
		if (thisItem == nil) { number } { thisItem }
		.reciprocal;
	}
}.();

pitches.postln;
rhythms.postln;

tempo = TempoClock.new( 63 / 60 );

rand = Pbrown(-0.005, 0.005, 0.00125);
rand = rand.asStream.nextN(tune.size);

rand.postln;

Ptpar([
	0, Pbind(
		\note, Pseq(pitches, 1) + 24,
		\dur, Pseq(rhythms, inf) + Pseq(rand, 1),
		\legato, Pseq(rhythms, inf) * 0.2,
		\pan, -0.3),
	2 + rand[0..7].sum, Pbind(
		\rand, Pseq(rand, 1),
		\note, Pseq(pitches, 1) + 12,
		\dur, Pseq(rhythms, inf) + Pseq(rand, 1),
		\legato, Pseq(rhythms, inf) * 0.4,
		\pan, 0.3),
	4 + (rand[0..7].sum * 2), Pbind(
		\rand, Pseq(rand, 1),
		\note, Pseq(pitches, 1),
		\dur, Pseq(rhythms, inf) + Pseq(rand, 1),
		\legato, Pseq(rhythms, inf) * 0.8,
		\pan, -0.6),
	6 + (rand[0..7].sum * 3), Pbind(
		\rand, Pseq(rand, 1),
		\note, Pseq(pitches, 1) - 12,
		\dur, Pseq(rhythms, inf) + Pseq(rand, 1),
		\pan, 0.6)
]).play(clock: tempo);
)
2

I am not seeing any late messages running this code over here. Is your system latency set very low? s.latency

3

s.latency returns 0.2. It is the default value.
Could it be an issue of m1-mac? My SC is 3.12.2 (Intel).

4

That shouldn’t be an issue.

Anything else you have in your startup file?
Have you been running the server for a long time (without reboot)?

5

Yes, the following is the startup.scd file.

s.options.numInputBusChannels = ~numIn = 21;
s.options.numOutputBusChannels = ~numOut = 21;
s.options.memSize = 2.pow(21);
s.options.device = "Fireface 800 (3F0)";

s.waitForBoot{
	var scrnWdth, scrnHght, numIn, numOut, meterWdth, meterHght, spectrogram;
	var spectrumWdth, serverGuiWdth, scopeWdth, stethoWith;
	scrnWdth = Window.screenBounds.width;
	scrnHght = Window.screenBounds.height;
	numIn = s.options.numInputBusChannels;
	numOut = s.options.numOutputBusChannels;
	meterWdth = { |numin, numout| ServerMeterView.getWidth(numin, numout) };
	meterHght = ServerMeterView.height;
	spectrumWdth = 400 + 82;
	serverGuiWdth = 290;

	s.plotTree;
	Window.allWindows.do{ |win|
		if (win.name == "localhost Node Tree") {
			win.bounds = Rect(0, (meterHght * 2) + 56, 300, scrnHght - (meterHght * 2) - 128) }
	};
	//ServerTreeGui.makeWindow(s);

	spectrogram = Window("Spectrogram", Rect(0, meterHght + 28, 300, meterHght)).front;
	~spectrogram = Spectrogram(spectrogram, Rect(0, 0, 300, meterHght)).start;

	FreqScope(spectrumWdth - 82, meterHght - 28);
	s.scope(2).view.bounds = Rect(spectrumWdth, 0, serverGuiWdth, meterHght);

	ServerMeter(s).window.bounds = Rect(
		spectrumWdth + serverGuiWdth, 0,
		meterWdth.(numIn, numOut), meterHght);

	Server.local.makeGui.window.bounds = Rect(
		spectrumWdth + serverGuiWdth + meterWdth.(numIn, numOut),
		0, serverGuiWdth, 100);

	Server.internal.makeGui.window.bounds = Rect(
		spectrumWdth + serverGuiWdth + meterWdth.(numIn, numOut),
		130, serverGuiWdth, 100);

	Server.internal.meter.window.bounds = Rect(
		spectrumWdth + serverGuiWdth + meterWdth.(numIn, numOut) + serverGuiWdth, 0,
		meterWdth.(2, 2), meterHght)
};
6

“Late” messages get posted when the message arrives in the server too late for it to be processed on time.

The server processes entire hardware blocks at once (not control cycles).

Block 0         Block 1         Block 2         ...
|...............|...............|...............|
                        ^ your synth here
            <-- ^ the message must arrive before here

So, latency should be at least as long as the hardware block (plus time for network transport and sclang interpreter execution). This is normally the case – even a 1024-sample block is only 23 ms at 44.1 kHz, where the default server latency is 200 ms.

The code is fine – no heavy processing.

I’ve seen in some Linux systems where the server and client time bases can get out of sync, when NTP updates the system clock. I don’t recall this being reported in Mac but I guess it’s not impossible. If this is the cause, it would run fine for a while, and then you would get a series of late messages for 15 to 20 seconds, and then they might stop. As I recall, that happened to me more often in Linux when starting SuperCollider shortly after waking from sleep – sclang would set its timebase before NTP adjusted the clock, after which adjustment, timing would be off.

You might try disabling NTP for a while and see if it goes away. Your system’s clock would drift away from the network reference (but, from time to time, you could reenable NTP, let the clock resync, then turn it off again).

hjh

3 Likes
7

@jamshark70 Thank you for sharing your experience and knowledge!

I unchecked

  • Set date and time automatically under “Date & Time” tap
  • Set time zone automatically using current location
    under “Date & Time” of System Preferences.

Now, it works as expected!
It seems to be resolved. If I confront the same problem, then I will report it again!

8

Very glad that helped!

This confused and worried me for some time until someone (I forget who) suggested on github that NTP might be the problem… which turned out to be correct. So I can’t fully claim credit.

hjh

1 Like