Iain Duncan

My understanding is that if overdrive is on and audio interrupt is checked, we get the audio and scheduler code running in the same thread, with one pass of the scheduler code running per audio vector, consuming as many message as it can handle each time, up the number in the Poll Throttle pref.

I would like to run a callback once per scheduler pass, which would also be once per "Signal Vector Size" samples, similar to running at krate in Csound. Or put another way, once at the temporal resolution that the scheduler actually runs against, which is of course not actually once per "tick". And I believe, if I'm reading things correctly, this would be once per "Scheduler Interval" ms if Audio Interrupt is not selected, and once per vector if it is. I'm wondering if there is a good way to do this? I can think of a few, but don't know if they would work:

- trigger a message based piece of code from the dsp vector perform routine - can one even do that or is one limited to doing nothing more than filling the audio vector from that routine?

- stick something on a protected queue once per audio vector calculation, with the callback running when the scheduler poll picks it up (which begs the question, how would the scheduler code poll to ensure getting the message each time)

- make a scheduled delay call using clock_fdelay and setting ms to be the (hopefully) right length. but is this reliable or will it potentially drift, eventually giving us either zero or two ticks in one vector?

- or maybe all I have to do is run some code in the scheduler, trigger the next callback by making a call to delay by some amount under audio vector ms and it won't get picked up off the internal queue until the next pass?

Anyone have thoughts or experiences in this?

I would like to run a callback once per scheduler pass, which would also be once per "Signal Vector Size" samples, similar to running at krate in Csound. Or put another way, once at the temporal resolution that the scheduler actually runs against, which is of course not actually once per "tick". And I believe, if I'm reading things correctly, this would be once per "Scheduler Interval" ms if Audio Interrupt is not selected, and once per vector if it is.  I'm wondering if there is a good way to do this?  I can think of a few, but don't know if they would work:

- trigger a message based piece of code from the dsp vector perform routine  - can one even do that or is one limited to doing nothing more than filling the audio vector from that routine?
- stick something on a protected queue once per audio vector calculation, with the callback running when the scheduler poll picks it up (which begs the question, how would the scheduler code poll to ensure getting the message each time)
- make a scheduled delay call using clock_fdelay and setting ms to be the (hopefully) right length. but is this reliable or will it potentially drift, eventually giving us either zero or two ticks in one vector?
- or maybe all I have to do is run some code in the scheduler, trigger the next callback by making a call to delay by some amount under audio vector ms and it won't get picked up off the internal queue until the next pass? 

Anyone have thoughts or experiences in this?
iain

My understanding is that if overdrive is on and audio interrupt is checked, we get the audio and scheduler code running in the same thread, 

SDK, how to run code once and only once per scheduler pass.