Right now, if I’m not mistaken, the only way to make a script “wait” for x milliseconds is to make a loop that will go on and freeze the UI layer until it’s done.
It would be pretty useful to have an interrupt based (like key handling) rest/sleep/wait function that we can call for short rests without freeze the UI.
I think it could be solved using
-- invoked periodically in the background, more often when the work load
-- is low, less often when Renoises work load is high.
-- The exact interval is not defined 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 here please!
renoise.tool().app_idle_observable
-> [renoise.Document.Observable object]
and
-- replaced with a high precision timer (still expressed in milliseconds)
os.clock() -> [number]
Have a look at the Nibbles script, which makes use of app_idle_observable in the way you are describing.
Example (untested code follows, look at nibbles if you want a real working example):
function loop()
-- Only run every 0.1 seconds
if (os.clock() - last_idle_time < 0.1 ) then
return
end
-- YOUR CODE HERE
-- Memorize time for the frame timer
last_idle_time = os.clock()
end
function run()
if not (renoise.tool().app_idle_observable:has_notifier(loop)) then
renoise.tool().app_idle_observable:add_notifier(loop)
end
end
Change 0.1 to the interval you need. The only issue is lack of precision. That is, it’s guaranteed not to run until, but could go over.
goddamn that is inefficient.
perhaps we need something like javascript’s setTimeout?
Well I haven’t tried renoise.tool().app_idle_observable yet…
That being said, the basic request still stands, having a real Rest function would be VERY useful. one that we can rely on and that can be set in milliseconds (instead of a semi accurate 0.x seconds)
I kinda second that request from the opposite end: if you want to do something every 5 minutes it would just feel horrible to check the time 10 times a second… sure, something has to keep track, but I’d prefer if the API did that.
Yeah, understandable… but we need this http://luajit.org/ to get this required speed and http://luajit.org/ is still Beta.
A timer function might indeed be handy, but it would do more or less the same thing than that what you could do now.
Performance wise this really is not a big thing, so LuaJit does not really help here.
Well, right now we can’t process real time user actions while a loop is in progress.
an Interrupt based timer would let the script wait for new user input and then go back to the desired function only at a precise and chosen interval.
Although os.clock() measures in seconds (double floating point number), it is damn precise. As precise as possible on the platform.
What I wanted to say is that, even if we put the timer function into the core, you would not really gain more precision. Such stuff has to be done in idle time for the UI.
I understand why you want this in your preclick tool, but to really solve the problem there, no UI timer will help you. You would need to do the stuff in realtime, in the Audio player, the soundcards thread.
But it would do it in C, not LUA? As opposed to running all as idle notifiers, ten times a seconds, and having the LUA code check if it’s time yet, the API would get the time once, run through through all registered notifiers and check if it’s time to fire them. If you keep the accuracy at “roughly .1 seconds” it would be the same, only that the notifiers don’t get called a billion times to twiddle their thumbs. Besides it would make such code a bit nicer to read/create.
Good point Johann,
Even if we don’t get more accuracy, it would be much nicer to work with and would require less processing power.
Maybe the devs will like this idea better, but it would also be great to have some kind of Trigger event function.
Being able to trigger a function when a condition is met. Say you run part of your script once and you set a trigger that will trigger some code once the Line number is 32 or when the selected instrument is equal to a defined variable.