Re: the time that the message was sent from scsynth

julian.rohrhuber-QYZGCWsIODmAF8UT6DzBU6xOck334EZe@public.gmane.org Fri, 2 Mar 2018 10:24:32 +0100
Newsgroups	gmane.comp.audio.supercollider.devel
Message-ID	<[email protected]>
> On 02.03.2018, at 02:47, [email protected] wrote:
> 
> ---- On Fri, 02 Mar 2018 00:16:21 +0800 <julian.rohrhuber-QYZGCWsIODmAF8UT6DzBU6xOck334EZe@public.gmane.org> wrote ----
>>> AFAIK, when receiving an OSC message, you have access to the timestamp (if it's a bundle), and otherwise the message carries no information at all about the sending time. In the latter case, all you have is the time of receipt... which varies according to network jitter etc.
>>> 
>>> AFAIK scsynth does not send send bundles back to the client. So the 'time' argument will not be reliable at millisecond scale.
>> 
>> I’m still not sure if it is the helpfile.
>> 
>> There seems to be no consistent timestamp also in other cases:
>> 
>> OSCdef(\x, { |msg, time| [msg[3], time, time - msg[3]].postln }, "/reply");
>> n = NetAddr("127.0.0.1", NetAddr.langPort);
>> 
>> // message
>> fork { loop { 1.wait; n.sendMsg("/reply", 0, 0, thisThread.clock.elapsedBeats) } };
>> 
>> // bundle
>> fork { loop { 1.wait; n.sendBundle(0.2, ["/reply", 0, 0, thisThread.clock.elapsedBeats]) } };
> 
> Hm, elapsedBeats doesn't look right to me. In SC clocks, "elapsed" refers to physical time rather than logical time. Logical time advances consistently according to rescheduling deltas ("1.wait"). Physical time lags behind and is inconsistent (depending on the speed of execution).
> 
> So it's quite possible that your bundle test here is measuring a consistent 'time' argument against an inconsistently advancing elapsedBeats.
> 
> This appears to be the case:
> 
> OSCdef(\x, { |msg, time| [msg[3], time, time - msg[3]].postln }, "/reply");
> n = NetAddr("127.0.0.1", NetAddr.langPort);
> 
> // message
> fork { loop { 1.wait; n.sendMsg("/reply", 0, 0, thisThread.clock.beats) } };
> [ 79.140106201172, 80.312176736, 1.1720705348281 ]
> [ 80.140106201172, 81.312177382, 1.1720711808281 ]
> [ 81.140106201172, 82.312140281, 1.1720340798281 ]
> 
> Using "beats" and no timestamp, msg[3] always increments exactly by 1, but the time argument includes some jitter.
> 
> // bundle
> fork { loop { 1.wait; n.sendBundle(0.2, ["/reply", 0, 0, thisThread.clock.beats]) } };
> [ 100.32391357422, 101.69571139384, 1.3717978196218 ]
> [ 101.32391357422, 102.69571139384, 1.3717978196218 ]
> [ 102.32391357422, 103.69571139384, 1.3717978196218 ]
> 
> With a timestamp, now the time argument is also exact.

Very good, this is clear now. I’ll see if I can add this result to the SendReply helpfile.
signature.asc (application/pgp-signature, 833 B)