I'm asking this here because what I'd like to do is something that pd does, so I suspect people here might know the answer. That is, you can have objects like delay that delay a bang or message. I'd like to, at first just for personal interest and pedagogical value, write a simple patcher-like system for managing the flow of events. I've tried to read some of the source code, but the size of it is overwhelming without some advice as to where in the source to read, and some idea of how pd is structured internally.

So suppose I wanted to write a pd-very-lite with no audio, just messages. The only objects would be 'bang', 'delay' and some kind of output (e.g. sending a midi CC or something). What sort of code do you have to write to get a reliable ms delay of an event?

More generally, again pedagogical value for now, how does one sequence midi events, or events in general, either when there is an audio thread to sync to, or without.

every object that delays contains a *t_clock. When you want to delay from within an object, you call clock_delay with that structure and the delay time. (and you can also set clock units)

clock_delay will take the pointer to t_clock and put it on the scheduling list, which is run through every 64 samples to the next 64-sample time

when you create the clock, with clock_new, you give it a callback "tick" function that will be called when the scheduler reaches that point in the scheduling list.

here are the time-based objects: https://github.com/pure-data/pure-data/blob/master/src/x_time.c

as for your second question, a more efficient way to do a scheduler is to use a heap-based priority queue. But you can also just use a regular list-based priority queue like pd does.

your scheduler basically has to tick every so often (and either sleep or spin in between), going through the scheduling queue (in pd this is pd_clock_setlist in m_sched.c) and popping off of the queue for every time value less than the next tick. In between your ticks get input from the ui and schedule things on the queue based on that.

I forget the details, but when audio is running the 'ticks' are based on calling the audio output api (or visa-versa?) every 64 samples.
you can see pd's scheduler here: https://github.com/pure-data/pure-data/blob/master/src/m_sched.c

actually if you aren't doing audio you can get away without using ticks (just 'sleep' until the next time in the queue) but you need to check for user input as well somehow, whether through interrupts or polling a queue periodically (or both). Idk that much about that latter part.

getting an accurate sleep can also be tricky, there are some articles on it.

@Chalisque Miller has a series of recorded lectures going through the internals of PD, fairly informative on this stuff, First couple lectures have some technical issues but they sort them out.
http://msp.ucsd.edu/syllabi/206.20s/index.htm

If you don't care of heaviness and dependencies, you very can use QT.
See https://doc.qt.io/qt-5/qtimer.html

@Chalisque

short answer: you have to make sure that the data runs in the high priority thread.

pd and max have a main thread, a high priority thread (overdrive), and an audio thread (among others)

how to do that in C++ is surely documented in the SDK examples, but i will not be of much help here.

maybe compare the source code of [+ ] vs. [delay], the latter outputs to the high priority thread if one exists.

@Obineg all of pd vanilla runs on 1 thread (well, the 'core' non-wish process anyways)
Message processing is simply interspersed w/ audio processing.

oh, i wasnt aware of that at all. so one could say there is basically no main thread? when the scheduler cant be turned off.:)

(scheduling events works fine: metro 1 -> click~ at vectorsizes 32 does what it is supposed to - in max it required the hp-thread to be available or it would produce hiccup.)

@Obineg Chapter 2.5 Scheduling..... http://puredata.info/docs/manuals/pd/x2.htm
David.

wow that is closer to live than to max.

There is a command line to launch pure-data without the audio engine.

flag -noaudio

@seb-harmonik.ar said:

@Obineg all of pd vanilla runs on 1 thread (well, the 'core' non-wish process anyways)
Message processing is simply interspersed w/ audio processing.

Almost. Pd does use a single thread for DSP and message processing, but this is not the same as the audio callback (unless "use callbacks" is enabled), so you have (at least) two threads.

Side note: In Pd, the audio callback does almost no work; it just reads/writes samples from/to a ringbuffer and returns. Pd's main thread waits on the ringbuffer (see sys_send_dacs), so it is indirectly (asynchronously) driven by the audio callback.