POV-Ray : Newsgroups : povray.off-topic : BPM : Re: New BPM Server Time
4 Sep 2024 13:20:13 EDT (-0400)
  Re: New BPM  
From: Invisible
Date: 9 Jun 2010 08:52:14
Message: <4c0f8e7e$1@news.povray.org>
Invisible wrote:

> I think what I need to do is perform a tapping experiment with a 
> timing source of known tempo, so I can get genuine error measurements. 

Heh, this is more difficult than you'd imagine.

I wrote a small program that basically does

   Get wall time.
   Save wall time to file.
   Print something to stdout.
   Wait X seconds.
   Repeat.

The amount of time is computed from the requested BPM. Only trouble is, 
when I analysed the resulting data, I discovered that the program is 
ticking too slowly. (E.g., I request 135 BPM, but I get 128 BPM.)

So then I tried having a thread that just does

   Send signal.
   Wait X seconds.
   Repeat.

and another thread that waits to receive a signal, and then does all the 
other stuff. But noooo, the timing accuracy has increased, but it's 
still ticking too slowly.

Thing is, what I want to do isn't "wait until X seconds from now", it's 
"wait until time X". But there isn't a function to do that. If there 
was, I could take the wall time now, compute the correct time for all 
future clock ticks, and schedule the thread to run at those times. But 
there isn't.

So I started digging through the library source code. Oh, this is fun: 
Internally the "wait X seconds" function is implemented using a "wait 
until time X" function. But it's private, so I can't call it. Thanks, 
guys...

Next plan: Write out a WAV file containing sonic pulses with the correct 
timing. Because, let's face it, there isn't much that can go wrong here.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.