Time problem with renoise.tool():add_timer(func,time)

R3.3.1 Win10 x64
I am experiencing precision issues with the timer to run a function repeatedly. When using:


I can’t get the timer to run below 60-62 ms. This could be used to create a repeat button, for example to shift the position of the line up or down.
The problem is that the timer seems to run very slow with a value in milliseconds below 60-70 ms.

For example, if you put 1000ms (1s), the timer will work practically perfect:


Up to about 70-80 ms it seems to work fine:


But if you use a value lower than 60 ms, the timer will keep running something above 60 ms always. I get the feeling that in previous versions of Renoise (v3.0 …), the timer could run at 10 and even 5 ms with a small margin of error.

Is it possible that add_timer now has a minimum limitation above 50 ms? We need a timer to work ultra-fast, which can reach up to 1ms speed. For example:


I have been experimenting with this code that I have purposely written to test it:

local C=0
local T=0
local function bang()
  local NC=os.clock()
  vws.TIME_TEXT.text=("T: %s | clock: %d ms"):format(T,(NC-C)*1000)
local function bang_timer()
  if not renoise.tool():has_timer(bang) then

local function gwt_frame()
  local FRAME=vb:row{
      tostring=function(value) return ("%d ms"):format(value) end,
      tonumber=function(value) return tonumber(value) end,
      text="Timer Test On/Off",
      notifier=function() C=os.clock() bang_timer() end
  return FRAME

It is even possible to notice that something is wrong simply by simply printing on the terminal.

Can anyone try this? If we cannot comfortably set a value between 10 and 100 ms, the timer is useless in many cases.

@taktik, can you review this matter in depth? Personally I use various tools with add_timer () remove_timer () and i’m experimenting serious slowness problems below 100 ms.

1 Like

I come back here to tell more about this matter.

For some reason, after starting Renoise, my computer lost an xml configuration file that stores all of Renoise’s preferences, “AppData\Roaming\Renoise\V3.3.1\Config.xml” I supose.

I assume that Renoise has restored this file with the default settings. I have no idea what the cause was. Previously I was manipulating OBS with a USB webcam. I don’t think it has anything to do with it.

Now the add_timer timer seems to work correctly. It seems that some specific setting that I had in Renoise previously was causing add_timer to not be as accurate as it was desirable.


Now it seems to work a lot better!

Everything has been quite strange for me. I would like to know why it was malfunctioning previously. If there is any Renoise specific setting that causes such a big imprecision in add_timer (func, time).

Continuing with the experience of this thread, I have noticed another strange thing.

After what happened to me above (Renoise restored the config XML by accident), I had the feeling that the timer was already running finer.

With limit frame rate to 60 fps:

But I still detect something strange. Far from being still accurate, the timer can return a still noticeable delay value. For example, the most extreme case is to set it to 1 ms:


Then it will return between 0 and 30 ms random response in each repetition. This is still very imprecise.

However, I have noticed that if I forcefully move the mouse pointer (just move it), the timer speeds up and acts at maximum precision, managing to almost constantly hit ~2ms:


I think this behavior should not happen. The timer should return as much precision as possible.

The problem is that if the programmer uses add_timer, they will get a delay of almost 30 ms, and it will be sped up if they move the mouse vigorously. What does the mouse have to do with add_timer?

Would it be possible to tune add_timer to always be as accurate as possible? I understand that a 5ms variation is justified, but not 30 ms.

Without limit frame rate:
Here what happens is that the timer cannot go below 60 ms (even if add_timer is in 1ms). It seems logical that the “limit frame rate” setting in Renoise’s preferences drastically influences add_timer().

I attach a tool for those who want to try it: com.ulneiz.TestAddTimer.xrnx (2.7 KB)

Is it possible to review all this and improve said behavior under the hood of Renoise?

The timer isn’t meant to be that precise. It’s called by Renoise from the GUI in idle, so under high work load the timing will be even worse. The precision also will vary from OS to OS and with various GUI settings (as you’ve already noticed).

Further, calling a Lua function in a timer every 10ms will create quite some noticeable workload, which should be avoided as well when possible.

So the real problem/question here is why you need such a high resolution timer at all?

I am aware of this and keep it in mind whenever I program LUA tools.

I use timers for various things within the tools. For example, a push-and-hold a button for navigation to repeat a function (for example, move between lines in the pattern editor), or the like. I also use it to check certain values at some point, sort of like a custom notifier.

If the timer is not able to go below 30ms, the repetition may be a bit slow. But it is strange that, with the “limit frame rate” activated and moving the mouse vigorously, the timer speeds up, reaching the desirable speed. What matters to me is not so much the precision, but that it works as fast as possible.

So if you use a valuebox to set the amount in ms, as long as the value is high, 50 ms, 100 ms, the user will hardly notice the difference. On the other hand, if the time value of add_timer is less than 30 ms, the timer will not work at that speed, (except if you move the mouse).

If you disable the “limit frame rate” the add_timer becomes very imprecise (I can’t get it to go below 60 ms.). I use an i7 6700K and an Nvidia GeForce GTX 1070 graphics card.

I hadn’t delved into this that much until now. I always thought that the timer had a “margin of error” of about 5ms, which is acceptable.