-- register a timer function or table with function and context (a method)
-- which gets periodically called with the app_idle_observable for your tool.
-- modal dialogs will avoid that timers are called. to create a one-shot timer,
-- simply remove the timer again in your timer function. timer_interval_in_ms
-- must be > 0. the exact interval your function will be called with, will vary
-- a bit, depending on the workload. when enough CPU time is available its error
-- will be around +- 5 ms
-- returns true when the given function or method was registered as timer
[added B4] renoise.tool():has_timer(function or {object, function} or {function, object})
-> [boolean]
[added B4] renoise.tool():add_timer(function or {object, function} or {function, object},
timer_interval_in_ms)
-- remove a previously registered timer
[added B4] renoise.tool():remove_timer(timer_func)
Thanks guys…I’ll give it a go. I should have read the doco a bit better. Spent all my time with the ViewBuilder and Song doco I didn’t even bother to check any of the other stuff.
Not having any luck at all!!!
I tried updating the dialog text on a timer which was firing ok until you click on the script start button. The timer then stops as it is obviously getting no CPU time while the script is running. When the script has finished the timer kicks back in and updates the dialog text. (Better late than never I suppose!). I have tried both timers with the same result (not surprising as they run on the same event I think).
I have also chopped up my code into smaller routines which has no effect whatsoever.
I have noticed one thing though. If I regularly display a prompt while the script is running it fixes both my problems. ie. As soon as the prompt displays it updates the text on the dialog window behind it and it also seems to reset the ‘time-out’ script timer. ie. It will never time out which is what I want and I see a few other users have the same problem. Now I have a couple of questions:
Is there anyway in code (without a mouse click) to close these prompts. I know it sounds crap but you could display a prompt and then quickly remove it just to refresh things. You probably wouldn’t even see it anyway. I tried to do this technique with another dialog window which I opened and closed rapidly but that also did not fix the problem. (I guess the thread is concentrating on the first dialog window instead).
The second thing I thought of is going back to the timers but I need some kind of ‘pause’ command which I could regulary call to slow the script down a bit and hopefully free up the CPU to give the timers enough time to fire…A much more eloquent solution.
Or is there any other thing I can call which will tell the GUI to update or cause a refresh? Any thoughts…
“idle” is always blocked by any modal windows, so my guess is its blocking out itself here. This could be quickly solved by not making the progress dialog modal.
But as conner said, it would help if you could provide some code you are working on then we could be a bit more specific?
I have some small issue with it though. When I use the process slicer class, each “process slice” generates its own undo step. Is there a way to avoid this?
released=function()
dialog:close()
if (not sliced_process or not sliced_process:running()) then
sliced_process = ProcessSlicer(split, vb.views.what.value, vb.views.implicit_off.value,
vb.views.copy_effects.value, vb.views.selection_only.value)
sliced_process:start()
end
split() --> this causes the yield error
end
I think the error is just misleading. This yields while not being called in a coroutine. Just a typo, isn’t it?
No, unfortunately theres no way to solve this at the moment.
Another problem is that the idle notifier gets not called for modal dialogs. And not running the process function modal allows the user to change stuff (insert/delete tracks, change the song in other ways), while your processing function is running.
In fladds example it will break or do strange stuff as soon as you delete the track its working on.
require "process_slicer"
local data = table.create()
data:insert('foo')
function build_data()
for i=1,5000000 do
for j=1,10000 do
data:insert(i + j)
end
coroutine.yield()
end
end
local process = ProcessSlicer(build_data)
process:start()
-- What do I put here?
rprint(data)
I am trying to use the process_slicer as seen in the Starter Pack/SVN but I don’t have any GUI elements to yield to.
The above code doesn’t work how I expect. rprint(data) prints before the script has a chance to do anything.
I’m trying to create a script that executes without complaining about running for too long, without having to update a GUI.
Tried a while loop, but that didn’t help as Renoise complained that my script was taking too long…
Actually, I have a bug and I’m not sure why. I’ve committed my WIP to SVN. (It’s the Midi Script). If someone could svn update to help me out that would be appreciated.
Steps to reproduce.
Reload Tools
Open the Terminal
Tools -> _Midi Script Debug (WIP)
File -> New Song
Tools -> _Midi Script Debug (WIP)
*** ./process_slicer.lua:123: std::logic_error: 'trying to access a nil object of type 'class RenoiseSong'. the object is not or no longer available.'
*** stack traceback:
*** [C]: in function 'error'
*** ./process_slicer.lua:123: in function <.><br>
<br>```
</.>
