Thanks Seb, that's helpful and gives me some stuff to chew on. Is the code in which you've done this public?
iain On Sun, Jun 13, 2021 at 9:40 PM Sebastian Shader via Pd-dev < [email protected]> wrote: > >1) Is the Pd clock scheduler only accurate to the ms or does it operate > at > >higher than ms accuracy? (As in, if I wanted to role my own mechanism > >closer to what Seb did, how frequently should my master time go off?) > > from what I can tell Pd seems to use its own unit of time in order to > interface better with the audio side of things, (but it's stored in a > double) > lua uses double for it's numbers, and I just used milliseconds (partially > because the pd clocks seem to work/have worked with milliseconds > primarily/historically) > > I'm not sure I understand "how frequently should my master time go off?" > You have the clock callbacks stored in the priority queue, and use the > scheduled time (in ms) for the keys the queue is sorted by. > So in order to "start a delay", you put a callback on the queue. Then to > start your scheduler, call the underlying t_clock delay with the value of > the difference between the time of the top value in the queue (which will > be the earliest callback because you set up the priority queue to sort as a > min-heap, so that the lowest times get popped out first) and the current > time. > Every time you return from the underlying t_clock callback, increment your > own time by the amount the underlying t_clock was called with/delayed for > (in milliseconds stored in a double, in my case). > > The nice thing about using t_clock is that you don't need to implement the > delay part yourself, just the priority queue and figuring out when to start > and stop it. (along with dispatching the callbacks associated with members > in the queue, wherever those go.) > > What I do is put my "main thread" on the queue to start. Every time > another thread/coroutine is started/sprouted it gets added to the queue. > Whenever a delay is encountered the current thread will be at the top of > the queue, so you just have to change the delay time and call some > downheap() function on the heap to restore the heap property after changing > the delay time in the priority queue member. (then delay the t_clock by the > new top member of the queue) > Every time a coroutine finishes I take it off of the top of the queue. > (and call another t_clock delay for the new top member, or stop if there > are none left) > > -Seb > > -----Original Message----- > Message: 2 > Date: Sat, 12 Jun 2021 11:11:12 -0700 > From: Iain Duncan <[email protected]> > To: pd-dev <[email protected]> > Subject: [PD-dev] More clock questions > > I have a couple more clock/schedule related questions after rereading the > comments from Miller and Seb. > > 1) Is the Pd clock scheduler only accurate to the ms or does it operate at > higher than ms accuracy? (As in, if I wanted to role my own mechanism > closer to what Seb did, how frequently should my master time go off?) > > 2) Miller made reference to the linked list of clocks that pd iterates > through. Is that something I could access directly? (and if so, where would > it live? > > 3) if anyone knows good books or online resources for learning more about > writing scheduler related code, I'm all ears! :-) > > thanks > iain > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
