[PD-dev] More clock questions

Iain Duncan iainduncanlists at gmail.com
Tue Jun 15 16:18:57 CEST 2021


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 <
pd-dev at lists.iem.at> 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 <iainduncanlists at gmail.com>
> To: pd-dev <pd-dev at lists.iem.at>
> 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
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210615/52c2b8ee/attachment.htm>


More information about the Pd-dev mailing list