For realtime or semi-realtime usage, you normally store the callbacks in a binary heap. (https://en.wikipedia.org/wiki/Binary_heap) A binary heap implemented in an array is both very efficient and quite simple: https://github.com/kmatheussen/radium/blob/master/common/PriorityQueue.hpp
You can look at Radium's scheduler, which uses a binary heap, here: https://github.com/kmatheussen/radium/blob/master/api/api_various.cpp#L4175 Example: (define (callback) (display "500ms later") 500) ;; I.e. call me again in 500ms. Return #f instead to stop being called again. ;; start it (ra:schedule 500 callback) ;; stop it (ra:remove-schedule callback) On Mon, Jun 8, 2020 at 6:06 PM Iain Duncan <[email protected]> wrote: > > Hi list, I'm hoping someone can give me some brief guidance as I'm sure this > is a solved problem in S7 and CM but is beyond my lisp knowledge for how to > do it correctly. > > Max/MSP has a scheduler that works with it's global clock. I want to enable > something like the following: > > (delay :4n '(my-funct a b c)) > > So the delaying side will be implemented in C, and that side will handle > converting :4n to the right time according to the max clock and then call > *something* in S7 from C at the right time. My question is what the right way > to store and then call the delayed function is, given that it might also have > anonymous elements > > (delay :4n (list (lambda (x) (...)) :foo :bar)) > > Ideally, the way this is done would be compatible with future plans to allow > a variant that we can cancel: > > (define future (delay :4n '(my-fun a b c))) > ... now I can cancel it by doing something to future if need be > > Do I need to do something like have my arg 3 to delay be converted to a > function and environment captured and stored with gensym? Is there a known > pattern for this that I can look at in the common music sources or other lisp > literature? Any help preventing slow wheel re-invention much appreciated! > > thanks > iain > > > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist _______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
