Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!
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..
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..
on cycle
local tStartMilliseconds
put the milliseconds into tStartMilliseconds
doStuff
send cycle to me in (700 - (the milliseconds - tStartMillseconds)) milliseconds
end cycle
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.
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
Coding in the Sun - So much Fun.
Visit http://electronic-apps.info for released App information.
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?
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.
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
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.
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
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.
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.
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.
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.
