Airmann, did you check this with LPB 8 ? Since I got those strange jumps only then, LPB 8. With LPB 4, everything seems to be ok. Or better say, the faster the LPB the more those jumps will be written. How should I or you fix this?
EDIT: For this I have a bit a fix it seems, using a timer instead… Since idle-timer is 10Hz? Far too slow… Isn’t it?
faderport.lua fix
[SPOILER]
function FaderPort:on_idle() if (not renoise.tool():has_timer(self.on_idle_real)) then
renoise.tool():add_timer(self.on_idle_real, 1000/250)
end
end
-- idle handler. We're called whenever the workload is low
-- average: 10 times per second:
-- TODO: high load and fader writes: Renoise restriction
function FaderPort:on_idle_real()
...
checked it out. I’m not sure if timers are faster than on_idle(), since they are called by app_idle_observable().
documentation says:
–[[
Register a timer function or table with a function and context (a method)
that periodically gets called by the app_idle_observable for your tool.
Modal dialogs will avoid that timers are called. To create a one-shot timer,
simply call remove_timer at the end of your timer function. Timer_interval_in_ms
must be > 0. The exact interval your function is called will vary
a bit, depending on workload; e.g. when enough CPU time is available the
rounding error will be around +/- 5 ms.
]]
and regarding app_idle_observable:
– Invoked periodically in the background, more often when the work load
– is low, less often when Renoise’s work load is high.
– The exact interval is undefined and can not be relied on, but will be
– around 10 times per sec.
– You can do stuff in the background without blocking the application here.
– Be gentle and don’t do CPU heavy stuff please!
renoise.tool().app_idle_observable
→ [renoise.Document.Observable object]
But maybe the internal call to app_idle_observable() is simply a timer with the parameter (1000/100) !
Anyway, I’ll check it out. If it’s faster we have the answer !
