Ernest

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?

cross-platform-reliability-of-high-resolution-timer

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.

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

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 )

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 )


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.

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.

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...)

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 )

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...

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...


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

Cross-platform reliability of high-resolution timer?