I’ve been bitten by the “Script no responding” thing with my tool. So although I don’t fully understand it, I tried using taktiks OneShotIdleNotifier. It goes fairly well, the script prints the final “done” which is the last thing it should do. However, renoise GUI freezes after this, and after a few seconds, I still get the “not responding” thing and renoise crashes.
EDIT: It doesn’t work well at all. The call seems to mess up stuff, now all samples are being deleted. I’ve commented out the use of OneShotIdleNotifier. But I’d still appreciate any hints regarding how to solve this.
I have not looked deeply into the script, but I personally am not a big fan of the OneShotIdle approach.
Why? Because it does simply schedule an action to take place at a later time, without knowing if the script or object that initiated the call will exist by then
Imho, a much better and more readable approach is to collect these updates by raising various flags.
So, if you have a tool which might update it’s user interface in response to the user scrolling through the pattern sequence you could get hundreds of those notifications in a short time. The ‘flags’ approach will simply receive these notifications, and raise a flag saying ‘something occurred which will require me to update the user interface’. Then, in your idle loop you could check those flags, perform the appropriate action and reset the flag back to normal.
So, the flag approach has the great advantage over OneShotIdle that your code never leaves the scope of your tool. It’s safe and relatively simple to implement.
But in your case, that isn’t exactly what is happening. You are not getting notifications, but rather sieving through the entire song, and this is quite hard to pull off using the ‘flag’ approach - doing the updates in the idle loop could strain the CPU less, but you would need to do a lot of internal ‘bookkeeping’ to keep track of progress.
Instead, there is a second approach which might be handy: lua co-routines. Basically, it will run your script in little “chunks”, never making the CPU suffer.
This approach has it’s own downsides, mainly that the undo buffer is potentially flooded and that it (once again) leaves the scope of the script.
However, it might be the right technique to use for this particular script, and should be simple to apply once you have encapsulated all of your processing logic into a single call -> “check_for_orphaned_samples”, or whatever you might call it.