Exact timing

Cool Dave · Post by **Cool Dave** » Sun Jul 01, 2012 3:03 am

This may sound like a strange problem, but it is really a very reasonable need.

I need to make something happen, say, every .7 seconds. Obviously,

Code: Select all

repeat while
doStuff
wait 700 millisecs
end repeat

or

Code: Select all

on cycle
doStuff
send cycle to me in 700 millisecs
end cycle

are not accurate enough.

There must be a accurate way to do this, but I have never found it. Can anyone help me with this?

Dave

shaosean · Post by **shaosean** » Sun Jul 01, 2012 9:09 am

My understanding is, unless you are using a real-time OS, your timing will never be 100% bang on, so you will have to live with the little bit of play each way on consumer OSes..

Code: Select all

on cycle
doStuff
send cycle to me in 700 millisecs
end cycle

Because you are doing the doStuff before you do the send, you will always have a bit of a delay due to the fact that doStuff may take shorter or longer to run, especially if you are doing disk or network access.. What you can always do is store the number of milliseconds at the beginning and end of doStuff and then subtract that from the 700 milliseconds to get something pretty close to be exact timing..

Code: Select all

on cycle
local tStartMilliseconds
put the milliseconds into tStartMilliseconds
doStuff
send cycle to me in (700 - (the milliseconds - tStartMillseconds)) milliseconds
end cycle

Cool Dave · Post by **Cool Dave** » Sun Jul 01, 2012 9:04 pm

That's kind of odd. I expected some way of noting exact time and then referring back to it.

Yes, there are many ways to send a message faster than those two ways I mentioned. Yours is one better way to do it. I was just showing the type of way I do it.

If I really end up needing it exact, I'll figure out some way and probably post it here. The important part to me is that they add up right, so at the end of an hour it has happened X number of times.

Thanks anyway,
David

dave_probertGA6e24 · Post by **dave_probertGA6e24** » Mon Jul 02, 2012 6:58 am

As a reference - how would you get more exact timing in another language - Java/C#/C/C++ for example?
I don't know the answer so this is an informational question

Cheers,
Dave

bn · Post by bn » Mon Jul 02, 2012 10:33 am

David,

you might want to have a look at Dar Scott's "A Primer on Message Mechanics 1.2.1"

http://pages.swcp.com/dsc/revstacks.html

It is a wonderful tutorial on, well message mechanics. It also looks at your problem. -> Synchronization and -> Scheduling

Kind regards

Bernd

jsburnett · Post by **jsburnett** » Tue Jul 03, 2012 10:14 pm

Hi,

Why not ..

on cycle
send cycle to me in 700 millisecs
doStuff
end cycle

That way the first instruction is always - 'repeat in 700 millisecs' irregardless of how long 'dostuff' takes. (I also assume 'dostuff' takes less than 700 millisecs) - or is this wrong?

John

bn · Post by bn » Tue Jul 03, 2012 11:04 pm

Hi John,

I guess you could do it that way.
But the original poster wanted exact timing. Although 700 milliseconds sounds pretty precise it is not guaranteed that the next message will arrive in exactly 700 milliseconds. If by chance Livecode is just busy with its housekeeping it could well be a couple milliseconds off. And this could accumulate. So it is best to do a check against the current millisecond and determine the next intervall.
Of course only if you want it to be more accurate than one needs in most cases.

But imagine a clock that runs a couple of hours on this.

Kind regards
Bernd

sritcp · Post by **sritcp** » Wed Jul 04, 2012 1:30 am

You could send a message to another custom command a few milliseconds before blast-off, and then count down continuously.

Code: Select all

on cycle
doStuff
send exactCycle to me in 690 millisecs
end cycle

on exactCycle
repeat until (the milliseconds - sTimeCountDownStarted) >= 700
end repeat
makeThingsHappen
end exactCycle

Regards,
Sri

Cool Dave · Post by **Cool Dave** » Tue Jul 10, 2012 9:54 pm

I didn't realize until now that there had been a bunch more replies. Sorry.

John, as Bernd said, that's not accurate enough for my liking. By tuning it, like maybe using 690, I can get it accurate enough for my needs though. I'm a bit of a perfectionist, so I wanted it nice and perfect. It was a counter app which was going to run on-stage, so I didn't want bugs. Turns out it wasn't used, but it probably will be needed next year. I'm onto other projects in the mean time, but I think I've figured out how to do it.

Code: Select all

on cycle
   if (field"delay" * field"flashes") < (the millisecs - field"startsecs") then
      doStuff
   end if
   if field"stopper" is "false" then
      send cycle to me in 100 millisecs
   end if
end cycle

on doStuff
   set the visible of image"frog" to true
   add 1 to field"flashes"
   wait for 100 millisecs with messages
   set the visible of image"frog" to false
end doStuff

I'll post my test stack here. Thanks everyone for your help!
Dave

Cool Dave · Post by **Cool Dave** » Tue Jul 10, 2012 10:00 pm

To test the accuracy, set the delay to 1000 and time it.

Reply here please, if it isn't.

bn · Post by bn » Tue Jul 10, 2012 11:04 pm

Hi Dave,

I attach a stack that shows what I mean to calculate a difference in send in time to compensate for time needed to display (in this case the seconds). Have a look at the comments in the script of the checkbox.

secondsWheel.livecode.zip: (4.67 KiB) Downloaded 295 times

Kind regards
Bernd

Edit: changed stack to 2.7 format

mwieder · Post by **mwieder** » Wed Jul 11, 2012 12:06 am

Bernd-

Nice scrolling wheel. I think you can accomplish the same thing a bit more easily, though, by queueing the send in 1000 milliseconds statement at the beginning of the handler and save having to calculate the difference. At least empirically it seems to work.

bn · Post by bn » Wed Jul 11, 2012 12:21 am

Mark,

thanks. Your version works very well. But the point here is to set the seconds in sync with the computer clock. In your version the seconds advance every 1000 milliseconds but not in sync with the computer. Admittedly this is a bordercase of send in time and synchronizing. So for most needs your version is the obviouse choice. But since Dave was stressing exactness I gave him this example.

And for the interleaving of a couple of send in time plus synchronizing here is a version of the secondsWheel that turns continuously and snaps to the second on the full second. The graphic is also a little nicer.

secondsWheelContinuous.livecode.zip: (5.51 KiB) Downloaded 292 times

Kind regards
Bernd

Edit: changed stack to 2.7 format

Cool Dave · Post by **Cool Dave** » Thu Jul 12, 2012 3:59 am

Hey Bernd and mwieder,

I'm guessing it's my older version of Livecode, but I can't open your test stacks.

Shouldn't my test stack work?

Dave

bn · Post by bn » Thu Jul 12, 2012 8:03 am

Hi Dave,

your stack works. I just wanted to show a send in time that also synchronizes to the computer clock and calculates the remaining time of the intervall.

What Mark Wieder says works pretty much the same as yours, except he sends the message before doing any time consuming action (which has to be shorter than the intervall of course) and thus the send in time arrives at the intended millisecond. A clever way around the problem of time spent during the actual execution of the handler.

Sorry, accidentally both my stacks were saved in 5.5 format. I changed both of them to 2.7 format and you should be able to open them.

Kind regards
Bernd

LiveCode Forums.

Exact timing

Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing

Re: Exact timing