Cross-platform reliability of high-resolution timer?

Jun 2, 2012 at 5:35am

Cross-platform reliability of high-resolution timer?

I paid a developer under NDA to develop private code for this function, but he bromke NDA and shared it. Then it appeared in the next Max 5 release. Not to say I was entirely pleased, he having taken over two thousand dollars for the work, but it being too little to make it worth taking him to court. But at least now I can use the Max function rather than his C++ code, which is easier. Sour grapes….

So he isn’t a very good at building C++ either, I learned. Thus I can’t be sure it works on a Macintosh at all. Is there anyone who’s used it on a Mac and who has tested its accuracy?

#56382
Jun 2, 2012 at 6:10am

Hello,

It has to be my English, but the accuracy of which object/things are you talking about ? I’m on mac 10.4.11 with max 5.1.7 ; and i can test it with [cpuclock] or even custom mach_absolute_time ( ) for exemple ; if i know what to measure ;-)

#202222
Jun 2, 2012 at 7:14am

Hi Nicolas. I’m sorry, I cna’t open Max on my laptop, and it’s too hot to turn on my i7. So I can’t seek the name now. I do rememeber it was more accurate than 1 millisecond.

#202223
Jun 2, 2012 at 10:12am

FWIW, the accuracy of [cpuclock] is 1 microsecond.

#202224
Jun 2, 2012 at 10:38am

Thank you Broc, I believe it was named [cpuclock], The stated accuracy may have been 1 mmicrosecond, but there are some concerns.

I verified the code which was written for me, which I beleive was invorproated into MAX, to be higher resolution than 1 millisecond, although I couldn’t be sure even that to be true in all instances.

This is because, historically, a pre-empotive hardware driver with a maximum-priority interrupt would be necessary, together with diagnostics of other hardware drivers to assure there are no interrupt conflicts. There is no such check obcvious in the MAX environment. And, I never verified its accuracy on a Macintosh machine either.

The code which i beleive was incorpaorated into MAX for [cpuclock] is from a cross-platform C++ library integration vendor. It is a small company with few resources internally to provide its own veritication.

Therefore the interface to the system clock timer, which is shared by many applications and the OS in Windows, is subject to conflicts with other hardware devices, and the specifics depend on how the library hooks into the hardware interrupts. I don’t know the specifics of that, so it could be, for example, other video hardware, or low-latency audio cards such as from RME and smiliar companies, could cause timing inaccuracy. I just don’t know, so I’m asking, as there could be developers in the Cycling’74 community who have needed accurate timing and performed there own evaluations.

If I can find 3rd party verification, for example by systems integrators for A/V workstations, then those sour grapes could turn out to be sweet after all )

#202225
Jun 2, 2012 at 1:24pm

Hello,

I’m currently working on a custom event-handler for fun to learn a bit more about threads ; i use nanoseconds mach_absolute_time ( ) for that ; but now that’s not cross-platform (and it will not be soon) ; anyway i’m not experienced enough to deal about Real Time Programming and such precision since i do not know anything about interrupt and hardware drivers ;-)

Sorry, Ciao.

#202226
Jun 2, 2012 at 5:10pm

So let me get this straight… you paid someone to develop some code for you, that you didn’t think was very well written, and that you further think was incorporated into Max a few years back, against your wishes. You don’t know what it may be called in Max, and it may or may not have higher than 1 ms resolution.

#202227
Jun 2, 2012 at 6:52pm

HI Chris…Did you used to work at Liberate? I’d be glad to e4xplain that later, but to expalin to Nicolas first:

Just because you command it to use nanosecons does not mean it actually is generating a clock that is accurate in nanoseconds.

#202228
Jun 2, 2012 at 10:15pm

Hi Crhis, no you didn’t as far as I know, I’m slowly remembering )

At the time, I only asked for millisecond resolution, so on that he exceeded expectations. He successfully created a thread with higher priority and created a callback routine to respond to timer events in C++, so that was very good. However his builds were terrrible. He told me in the first place he needed a build engineer, but I’m too small an outfit to provide that service. And I learned why he needed a build engineer…oh yes…)

#202229
Jun 3, 2012 at 5:48am

Hello,

“… does not mean it actually is generating a clock that is accurate in nanoseconds.”

Yep, i know, but i only needed milliseconds resolution so it doesn’t matter ; that was the only (in case of) portable way. In my project i only need average precision, i mean that if the process is interrupted by something i can reduce the quantum next to keep in timing. I have no idea how to implement an absolute precision timer, for this kind of high accuracy you probably need to create a thread with RT policy and avoid malloc () global lock and so … I do not know how to make reliable measures for those tiny slices of time … but we are not in the dev forum and i’m not an engineer ;-)

What kind of precision do you really want and what’s for ?

#202230
Jun 3, 2012 at 6:50am

I’m glad it does what you want, and thank you for letting me know cpuclock works on macs. I’ll be glad to share some more when I have something more substantial to share )

#202231
Jun 3, 2012 at 2:09pm

curious post … why do you think your code has made it into the Max5+6 distribution?
[cpuclock] has been part of Max 4, I think I have been using this object even in Max 3.6, so that would be more than 10 years ago…

#202232
Jun 3, 2012 at 9:47pm

Aha, so it was available previously on the Mac. Big help, thank you )

#202233

You must be logged in to reply to this topic.