Mattijs

I can't find a native or 3rd party external that reports system time with a millisecond accuracy. [date] does it, but only with 1/60 second precision, which is not enough for my purposes.

[cpuclock] also won't work because I need to sync different instances of max.

Does anyone know of an object that does this?

I can't find a native or 3rd party external that reports system time with a millisecond accuracy. [date] does it, but only with 1/60 second precision, which is not enough for my purposes. 

is-there-an-accurate-way-to-acquire-system-time-not-date

> I can't find a native or 3rd party external that reports system time

> with a millisecond accuracy. [date] does it, but only with 1/60

> second precision, which is not enough for my purposes.

> [cpuclock] also won't work because I need to sync different instances

You should be able to sync cpuclock by just banging over the network, 

and substract the current value of cpuclock on each instance. That 

should be within a millisecond of accuracy...

Mattijs Kneppers schrieb:
> I can't find a native or 3rd party external that reports system time
> with a millisecond accuracy. [date] does it, but only with 1/60
> second precision, which is not enough for my purposes.
>
> [cpuclock] also won't work because I need to sync different instances
> of max.

You should be able to sync cpuclock by just banging over the network, 
and substract the current value of cpuclock on each instance. That 
should be within a millisecond of accuracy...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

There is a network connection between the two instances of max (running on the same computer) but I'm already sending a lot of data over that connection. So it is not reliable enough.

Actually that is exactly the reason why I need an exact time reference (system time) in both apps: to check the latency of the network.

Quote: Stefan Tiedje wrote on Tue, 06 November 2007 15:22

----------------------------------------------------

> You should be able to sync cpuclock by just banging over the network, 

> and substract the current value of cpuclock on each instance. That 

> should be within a millisecond of accuracy...

> #P number 57 206 93 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 114 76 117 196617 r systemwidetrigger;

There is a network connection between the two instances of max (running on the same computer) but I'm already sending a lot of data over that connection. So it is not reliable enough. 

Quote: Stefan Tiedje wrote on Tue, 06 November 2007 15:22
----------------------------------------------------

> You should be able to sync cpuclock by just banging over the network, 
> and substract the current value of cpuclock on each instance. That 
> should be within a millisecond of accuracy...
>
> Stefan
>
> #P window setfont "Sans Serif" 9.;
> #P number 57 206 93 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 57 92 15 0;
> #P window linecount 1;
> #P newex 57 114 47 196617 metro 2;
> #P newex 57 174 67 196617 -;
> #P newex 57 141 50 196617 cpuclock;
> #P newex 114 76 117 196617 r systemwidetrigger;
> #P button 114 110 15 0;
> #P newex 114 141 50 196617 cpuclock;
> #P connect 4 0 7 0;
> #P connect 6 0 5 0;
> #P connect 5 0 3 0;
> #P connect 0 0 4 1;
> #P connect 3 0 4 0;
> #P connect 2 0 1 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 8;
>
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
>
>
----------------------------------------------------


Maybe you could connect the computers via an audio or MIDI cable as well.

> Does anyone know of an object that does this?

> software for interactive audiovisual sampling 

Mattijs Kneppers wrote:
> Hi,
>
> I can't find a native or 3rd party external that reports system time
> with a millisecond accuracy. [date] does it, but only with 1/60
> second precision, which is not enough for my purposes.
>
> [cpuclock] also won't work because I need to sync different instances
> of max.
>
> Does anyone know of an object that does this?
>
> Thanks, Mattijs -- SmadSteck - http://www.smadsteck.nl Hard- and
> software for interactive audiovisual sampling 
>
>


Quote: jasch wrote on Tue, 06 November 2007 20:05

Thanks jasch, this is exactly what I need!

Quote: jasch wrote on Tue, 06 November 2007 20:05
----------------------------------------------------
> try my [timestamp] external
>
> /*j
>

> Actually that is exactly the reason why I need an exact time

> reference (system time) in both apps: to check the latency of the

I think the system time internally isn't reported more exact. Elsewise 

you could try also java. I am sure you can ask the system for a time 

For latency of the network, there is also ping by the way...

Mattijs Kneppers schrieb:
> Actually that is exactly the reason why I need an exact time
> reference (system time) in both apps: to check the latency of the
> network.

I think the system time internally isn't reported more exact. Elsewise 
you could try also java. I am sure you can ask the system for a time 
from there as well...
For latency of the network, there is also ping by the way...

> There is a network connection between the two instances of max

> (running on the same computer) but I'm already sending a lot of data

> over that connection. So it is not reliable enough.

What just comes to mind, use Midi to trigger the time stamp. That should 

arrive on each instance at the same time and is not affected by the 

Mattijs Kneppers schrieb:
> There is a network connection between the two instances of max
> (running on the same computer) but I'm already sending a lot of data
> over that connection. So it is not reliable enough.

What just comes to mind, use Midi to trigger the time stamp. That should 
arrive on each instance at the same time and is not affected by the 
network...

I believe the best way to make playback accurate is to fetch an accurate time stamp -before- sending a message over the network, then placing this event into a (100 ms or so) buffer at the position of the time stamp, and then playing it back at the correct time + 100ms.

I had this working, the buffer worked with seq~. This worked very well but seq~ appears to crash often when deleting events. So now I'm looking into a coll based solution.

Quote: Stefan Tiedje wrote on Wed, 07 November 2007 19:16

> > Actually that is exactly the reason why I need an exact time

> > reference (system time) in both apps: to check the latency of the

> I think the system time internally isn't reported more exact.

Both [cpuclock] and Jasch's [timestamp] appear to have a maximum resolution when used inside a pluggo. But [timer] doesn't(?). Have a look at this movie that is simply a metro connected to a timer and cpuclock inside a plugin:

Jasch, timestamp behaves the same as cpuclock, it never amounts to exactly 500 ms. Would you know why? The pluggo developer doc says that the scheduler defaults to audio interrupt mode inside pluggo. The movie would demonstrate that the scheduler is served only every 20 milliseconds inside pluggo.

But how come [timer] reports the correct interval? Does it report the correct interval because it uses the -supposed- time instead of the real time to determine the interval?

All very interesting and very undocumented..

Quote: Stefan Tiedje wrote on Wed, 07 November 2007 19:16
----------------------------------------------------
> Mattijs Kneppers schrieb:
> > Actually that is exactly the reason why I need an exact time
> > reference (system time) in both apps: to check the latency of the
> > network.
>
> I think the system time internally isn't reported more exact. 

But how come [timer] reports the correct interval? Does it report the correct interval because it uses the -supposed- time instead of the real time to determine the interval? 

Quote: Mattijs wrote on Wed, 07 November 2007 10:36

> Quote: jasch wrote on Tue, 06 November 2007 20:05

> ----------------------------------------------------

> Thanks jasch, this is exactly what I need!

timestamp's smallest interval seems to be 16,66 ms. Below is a patch that demonstrates this.

So timestamp too has a maximum resolution of 60th seconds, just like date.

Does someone know whether this is a limitation imposed by the max scheduler or by the system?

Quote: Mattijs wrote on Wed, 07 November 2007 10:36
----------------------------------------------------
> Quote: jasch wrote on Tue, 06 November 2007 20:05
> ----------------------------------------------------
> > try my [timestamp] external
> >
> > /*j
> >
>
> Thanks jasch, this is exactly what I need!
>
> Mattijs
----------------------------------------------------

So timestamp too has a maximum resolution of 60th seconds, just like date. 

I've not looked for a while, but the tod (time of day) clock used on Mac hardware used to be, at best, accurate to 1/60 second (1 'tick'). The software that accessed this could be off by a tick or two.

The Mac has hardware clocks that are supposed to give you higher accuracy than this, but only relative to boot time. Not much help across a multi-computer network, but you said something about sync'ing two different apps on a single machine. So this might do. I am not aware of a ready-made external that accesses the Mac OS Time Manager. It's a relatively obscure part of the Mac OS API and has changed a couple of times, something people aren't likely to play with just for the fun of it. But you might find someone to build a custom external for you, if you really want to go this route.

If you want to contact me off-list to talk about this, please feel free.

Quote: Peter Castine wrote on Mon, 12 November 2007 15:10

> I've not looked for a while, but the tod (time of day) clock used on Mac hardware used to be, at best, accurate to 1/60 second (1 'tick'). The software that accessed this could be off by a tick or two.

Ah, that explains. Thanks for this info Peter!

> The Mac has hardware clocks that are supposed to give you higher accuracy than this, but only relative to boot time. Not much help across a multi-computer network, but you said something about sync'ing two different apps on a single machine. So this might do. I am not aware of a ready-made external that accesses the Mac OS Time Manager. It's a relatively obscure part of the Mac OS API and has changed a couple of times, something people aren't likely to play with just for the fun of it. But you might find someone to build a custom external for you, if you really want to go this route.

You're right, there is a microseconds() routine, interesting. But I see what you mean with the obscurity. On a single machine, that's right, so relative to boot time would be perfect.

When working with multiple computers I wouldn't trust the system times to be exactly equal anyway. That would need an additional sync system (for example with midi, as Stefan mentioned).

> If you want to contact me off-list to talk about this, please feel free.

I will keep that in mind, thanks. There are a few more standard max paths I'm trying before bothering you with this ;)

Quote: Peter Castine wrote on Mon, 12 November 2007 15:10
----------------------------------------------------
> I've not looked for a while, but the tod (time of day) clock used on Mac hardware used to be, at best, accurate to 1/60 second (1 'tick'). The software that accessed this could be off by a tick or two.

>
> The Mac has hardware clocks that are supposed to give you higher accuracy than this, but only relative to boot time. Not much help across a multi-computer network, but you said something about sync'ing two different apps on a single machine. So this might do. I am not aware of a ready-made external that accesses the Mac OS Time Manager. It's a relatively obscure part of the Mac OS API and has changed a couple of times, something people aren't likely to play with just for the fun of it. But you might find someone to build a custom external for you, if you really want to go this route.

You're right, there is a microseconds() routine, interesting. But I see what you mean with the obscurity. On a single machine, that's right, so relative to boot time would be perfect. 

>
> If you want to contact me off-list to talk about this, please feel free.

I may have missed something (just busting through thousands of emails 

after a vacation), but the 'cputime' object is pretty useful.

I may have missed something (just busting through thousands of emails  
after a vacation), but the 'cputime' object is pretty useful.

Quote: Jeremy Bernstein wrote on Mon, 12 November 2007 18:05

> I may have missed something (just busting through thousands of emails 

> after a vacation), but the 'cputime' object is pretty useful.

Hi Jeremy, welcome back to the keyboard ;)

I believe you are referring to the cpuclock object. cpuclock reports the time since max startup. I'm trying to sync a pluggo and max. Pluggo behaves like a different instance of max so cpuclock reports different values at the same time in pluggo compared to max.

Also, would you know how to explain the following behaviour?

Quote: Jeremy Bernstein wrote on Mon, 12 November 2007 18:05
----------------------------------------------------
> I may have missed something (just busting through thousands of emails  
> after a vacation), but the 'cputime' object is pretty useful.
>
> jb
>
----------------------------------------------------

Quote: Mattijs wrote on Mon, 12 November 2007 20:21

---------------------------------------------------- 

> Also, would you know how to explain the following behaviour?

timer and cpuclock are measuring two different things, so naturally the results are different.

The timer object works relative to the Max scheduler, so two bangs produced by, say, [metro 500] (ie, the Max scheduler) and measured by timer (ie, the Max scheduler) will always be exactly 500 'scheduler milliseconds' apart.

Cpuclock works relative to a hardware clock and will therefore pick up any jitter in the Max scheduler.

Quote: Mattijs wrote on Mon, 12 November 2007 20:21
---------------------------------------------------- 
> Also, would you know how to explain the following behaviour?
>
> http://www.smadsteck.nl/plugintiming.mov
----------------------------------------------------

The timer object works relative to the Max scheduler, so two bangs produced by, say, [metro 500] (ie, the Max scheduler) and measured by timer (ie, the Max scheduler) will always be exactly 500 'scheduler milliseconds' apart. 

Cpuclock works relative to a hardware clock and will therefore pick up any jitter in the Max scheduler.


Quote: Peter Castine wrote on Tue, 13 November 2007 10:50

> Quote: Mattijs wrote on Mon, 12 November 2007 20:21

> ---------------------------------------------------- 

> > Also, would you know how to explain the following behaviour?

> timer and cpuclock are measuring two different things, so naturally the results are different.

> The timer object works relative to the Max scheduler, so two bangs produced by, say, [metro 500] (ie, the Max scheduler) and measured by timer (ie, the Max scheduler) will always be exactly 500 'scheduler milliseconds' apart.

Ah, I already suspected that, thanks for confirming. (Pity these things are nowhere to be found in any documentation. Wouldn't it be a good idea to query Peter's brain with *MaxMSP*.* and write the results to a text file?)

> Cpuclock works relative to a hardware clock and will therefore pick up any jitter in the Max scheduler.

So looking at the movie, this means that inside a plugin the scheduler has a minimum interval of around 24 ms? Is this because it is in audio interrupt and the vector size is big (24 ms -> 1024 samples)? Shouldn't the 'accurate' flag fix this?

Quote: Peter Castine wrote on Tue, 13 November 2007 10:50
----------------------------------------------------
> Quote: Mattijs wrote on Mon, 12 November 2007 20:21
> ---------------------------------------------------- 
> > Also, would you know how to explain the following behaviour?
> >
> > http://www.smadsteck.nl/plugintiming.mov
> ----------------------------------------------------
>
> timer and cpuclock are measuring two different things, so naturally the results are different.
>
> The timer object works relative to the Max scheduler, so two bangs produced by, say, [metro 500] (ie, the Max scheduler) and measured by timer (ie, the Max scheduler) will always be exactly 500 'scheduler milliseconds' apart. 

Ah, I already suspected that, thanks for confirming. (Pity these things are nowhere to be found in any documentation. Wouldn't it be a good idea to query Peter's brain with *MaxMSP*.* and write the results to a text file?) 

> Cpuclock works relative to a hardware clock and will therefore pick up any jitter in the Max scheduler. 

You can get millisecond accuracy using java in your patch. (Just how I don't know as I've never used java in Max.)

This will return the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC.

If you regularly call this method you will have an exact time to sync to.

You can get millisecond accuracy using java in your patch. (Just how I don't know as I've never used java in Max.)
The call in java would be:
System.currentTimeMillis();
This will return the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC.

If you regularly call this method you will have an exact time to sync to.


Is there an accurate way to acquire system time (not [date])?