I’m using the latest stable Juce version (1.53) and I’ve been having problems with the Juce’s Timers.
I use them for a kind of debouncing system (want to prevent an action from being repeated really too fast). On each action trigger, startTimer is called, and then any incoming action request is blocked till it reaches the timerCallback (where stopTimer is called).
Here’s my problem:
The timerCallback is very often processed really earlier than expected. For instance, with a 20ms timer, it gets called after only 3ms (or even 1, this time varies a lot).
Note I use getMillisecondsHiRes to compute the delay between the startTimer and the timerCallback.
I obviously expect the Timer not to be very precise (as written in the Timer comments) but can’t figure out how, nor why, the time can be so different and short!
Last but not least, by adding some debug output in Timers’ code (in startTimer and callTimers), i noticed that for any Timer running in Juce, the first callback is often called very early, but that’s less annoying when you want an action to be repeated and not only one callback.
I mainly have this issue using PCs running Win7, haven’t tested on Mac or Linux yet.
Read the forum.
The latest stable version is not 1.53, use git, and download the current version. Test your issue, and if it’s still not fixed, post a more detailed bug here.
I wonder where do you find I wasn’t “kind” ?
I’ve given you an advice plus 3 actions to perform, before anyone on the forum will be able to answer you.
There’s only ONE sticky thread on this forum, I wonder who you’re going to insult because you haven’t read it…
Do what I’ve told you and then you’ll suddenly find a bench of people being inclined to grasp your issue.
Persist in your attitude, and you won’t get any answer, not because we don’t like you, but simply because no one here bother to maintain one year old code.
Cylvoon, read this: http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=4950
…and if you still have an issue with today’s version of the code and really do think it’s a juce bug, then please post a quick code snippet that I can use to reproduce it. Thanks!
@X-Ryl669
Ok, doesn’t matter if you think I haven’t read the sticky post.
I read it, and that’s it.
For me, being kind means to say hello, and not to tell people to do what they’ve already done.
But, I don’t want to fight with you. Forget it, and really sorry if you misunderstood my post.
I know this sticky and read it several times.
However, can you confirm the 1.53 is the latest stable release version ?
I’m using a commercial version of Juce and just can’t clone the git repo to test the latest tip (as I won’t use it till it’s officially released and my boss decide to upgrade).
I think i given quite many details about my issue, but if not please tell me what kind of information is missing.
I’ll try to provide a code snippet asap, with 1.53 but afaik, Timers haven’t changed so much in latest tip.
Thanks again,
Cylvoon
Edit: I’m using VS2010, 32-bits build, running on either a win7 32 or 64.
It’s the last one that I published as an “official” release, but the codebase has changed massively since then, so there’s really not much point in reporting problems unless you know that they’re still there in the latest version.
I think I would agree with cylvoon, we kind of encounter the same issue here.
We have several timers and multi-timers, and they all get called most of the time earlier than expected. It seems to be completely random, and globally, timers are called up to the 6th of their initial time value.
We’re currently investigating to find any clue about this, we’ll keep you up to date about this.
We’re at the head of the GIT repo, but we have this issue since a while now (1.53).
We have the same issues on both win/mac, not matter the OS version or the architecture.
The time interval isn't guaranteed to be precise to any more than maybe
10-20ms, and the intervals may end up being much longer than requested if the
system is busy. Because the callbacks are made by the main message thread,
anything that blocks the message queue for a period of time will also prevent
any timers from running until it can carry on.
They run on the message thread, so they’re at the mercy of other messages, and are definitely not intended for anything that requires even moderate precision.
We are aware of this, but even with 100+ms timer we are getting huge variation. But you’re right, as the timers calls occur in the message thread, we can’t rely on them for accurate operations.
We’ll use something else instead, boost’s ASIO or other.
It’s obvious being at the mercy of other messages can slow down a timer, but just for my understanding, how a timer callback can be called too early?
Thanks.[/quote]
e.g. if a 10ms timer gets called at 0, 10, 20, 35, 40, then you might mistakenly think the 40ms callback happened early.[/quote]
Thank you for the quick reply and this explanation.
However, it doesn’t correspond to what I experienced, as I measured the time between the call to startTimer and the first timerCallback (using a timer as a one-shot countdown).
In this case, the timer callback is often called earlier than expected, and I can’t see how being at the mercy of other messages can be the cause.
Well, I don’t know. If it matters to you, have a dig around in the implementation, but honestly, if you’re sufficiently bothered that you’re taken the trouble to measure their performance, then you’re not the target audience for them!
Sure, I clearly understood they’re not designed for accurate short timers, and found an alternative solution. But was just trying to find a correlation between “the timers can be late, cause at the mercy of other messages” and “the timers are early”.
