Page 1 of 2
Exact timing
Posted: Sun Jul 01, 2012 3:03 am
by Cool Dave
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
Re: Exact timing
Posted: Sun Jul 01, 2012 9:09 am
by shaosean
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
Re: Exact timing
Posted: Sun Jul 01, 2012 9:04 pm
by Cool Dave
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
Re: Exact timing
Posted: Mon Jul 02, 2012 6:58 am
by dave_probertGA6e24
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
Re: Exact timing
Posted: Mon Jul 02, 2012 10:33 am
by bn
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
Re: Exact timing
Posted: Tue Jul 03, 2012 10:14 pm
by jsburnett
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
Re: Exact timing
Posted: Tue Jul 03, 2012 11:04 pm
by bn
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
Re: Exact timing
Posted: Wed Jul 04, 2012 1:30 am
by sritcp
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
Re: Exact timing
Posted: Tue Jul 10, 2012 9:54 pm
by Cool Dave
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
Re: Exact timing
Posted: Tue Jul 10, 2012 10:00 pm
by Cool Dave
To test the accuracy, set the delay to 1000 and time it.
Reply here please, if it isn't.
Re: Exact timing
Posted: Tue Jul 10, 2012 11:04 pm
by bn
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.
Kind regards
Bernd
Edit: changed stack to 2.7 format
Re: Exact timing
Posted: Wed Jul 11, 2012 12:06 am
by mwieder
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.
Re: Exact timing
Posted: Wed Jul 11, 2012 12:21 am
by bn
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.
Kind regards
Bernd
Edit: changed stack to 2.7 format
Re: Exact timing
Posted: Thu Jul 12, 2012 3:59 am
by Cool Dave
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
Re: Exact timing
Posted: Thu Jul 12, 2012 8:03 am
by bn
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