Re: the time that the message was sent from scsynth

---- On Fri, 02 Mar 2018 00:16:21 +0800 <julian.rohrhuber-QYZGCWsIODmAF8UT6DzBU7NAH6kLmebB@public.gmane.orgt> 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.

hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/