Pseudo Realtime Using Co-Routines

hi there!

i’m attempting to make some kind of automation of the loop points in the sampler.
so far, i’ve gotten this:

quit = false  
multiplier =[1].samples[1].sample_buffer.number_of_frames  
function amount() return[1].devices[2].parameters[4].value end  
while quit == false do  
 if [buttonpressed] then quit=true end -- havent made the gui yet ![:)](  
 if amount() >= 0.0001 then[1].samples[1].loop_end = amount() * multiplier  
 else[1].samples[1].loop_end = 1  

this grabs the value of an amplification slider of an lfo (which is itself controlled by another lfo, workaround for a free automatable slider ;) ),
mutliplies it by an multiplier defined by the samples length, so it wont get out of bounds, and feeds it into the loop end point position.

now, this script doesnt work, its obvious.
The problem is here, that if i have a script running it just goes through - hardcore mode.
now if i had the possibility to tell it, do it one time, then return to whatever the host was doing, and then, maybe after 10ms, return to the loop,
it could work, as its not hogging the cpu.

i know this could be done by “coroutine.yield()” and “coroutine.resume()”, but the problem is, i only know how to get to another lua “thread” and then back again.
that doesnt help much. i would have to return to the host, and then somehow, trigger a resume from it.

another approach i tried was creating a dialog with a slider, linked to the looppoint. but i havent got a clue on how to link this slider to something else to automate it (lfo or so)

anybody got an idea, or suggestion on how to achieve this? or is it even impossible to do so?
or maybe a completely different approach?

thanks ahead

Yes! That was exactly what i was looking for, thanks alot.
Now if it only were possible to include any changes made to the looppints in the rendering process :), but thats not going to happen i suspect. Record line-out ftw.

Anyways, now im going to make some nice interface to select every available sample and control, link them up, choose the looppoint priority (start pushing end along, or other way around)…

hopefully itll be useful for somebody besides me.

Oh, now another thing comes to mind:

when the looppoint gets changed by my script, it records every change, that means it spams the undo stack indefinetly.
is there a way to prevent those changes to get into the undo/redo list?