Hi, I'm having trouble scheduling/recording events with less than 20ms time resolution. I want actually 5ms, but specifying a clock this fast makes things jitter all over the place. I tried optimizing Max scheduler preferences (details below). I wonder if anyone else has encountered this problem and what is the common workaround (direct use of system clocks(?))

I have several clocks inside my external, but the one that takes care of timestamping, seems to be the problem.

First, in the object "new" function I create and start the clock:

void *XDelay_new(t_symbol *s, long argc, t_atom *argv)

x->m_microclock = clock_new((t_object *)x, (method)XDelay_microclock_task);

clock_fdelay(x->m_microclock, 1000.*ClockDefaults::MicroClockTimeSec);

Then I set the clock to repeat in the task, while calling a method MicroTick() that does nothing but accumulate a time elapsed in seconds (so just "+=": not time consuming at all on this thread)

When MicroClockTimeSec > 0.02 (20 ms), things work perfectly, but only up to 20ms resolution as expected. 

When MicroClockTimeSec = 0.01 or 0.005, I get errors up to 100ms (!)

Hi, I'm having trouble scheduling/recording events with less than 20ms time resolution. I want actually 5ms, but specifying a clock this fast makes things jitter all over the place. I tried optimizing Max scheduler preferences (details below). I wonder if anyone else has encountered this problem and what is the common workaround (direct use of system clocks(?)) 

void *XDelay_new(t_symbol *s, long argc, t_atom *argv)
{
...
x->m_microclock = clock_new((t_object *)x, (method)XDelay_microclock_task);
...
clock_fdelay(x->m_microclock, 1000.*ClockDefaults::MicroClockTimeSec);
...
}

void XDelay_microclock_task(t_XDelay *x)
{
    x->p_mgr->MicroTick();
    clock_fdelay(x->m_microclock, 1000.*ClockDefaults::MicroClockTimeSec);
}

void XDelayScheduleMgr::MicroTick()
{
    m_timeSec += m_microClockIntervalSec;
}

When MicroClockTimeSec > 0.02 (20 ms), things work perfectly, but only up to 20ms resolution as expected. 
When MicroClockTimeSec = 0.01 or 0.005, I get errors up to 100ms (!)

My scheduler preferences are as follows:
Event Interval = 1ms
Overdrive = checked
Poll Throttle = 20
Queue Throttle = 10
Redraw Queue Throttle = 1000
Refresh rate (ms) = 33.333332
Scheduler Interval (ms) = 1
Scheduler Slop (ms) = 0

Thanks for any advice!

Hi, I'm having trouble scheduling/recording events with less than 20ms time resolution. I want actually 5ms, but specifying a clock this fas

sloppy-clocks-with-clock_fdelay

According to the manual [1], the “event interval” option controls the *low-priority queue* polling rate, and all timing events are processed by the *scheduler*. From your report it seems that Max services the scheduler every 20 ms, which is kind of a high value for a real-time app, so take my speculation with a grain of salt.

You can try enabling the “Scheduler in Audio Interrupt” option from the DSP settings (see [2]). If I understand correctly, it’ll make Max to behave more like PureData and process scheduler tasks on each signal vector. Thus, the time granularity of your messages and clocks will be locked to the signal vector size (don’t confuse with the I/O size). By default it equals to 64 samples or ~1,45 ms at 44100 Hz s/r.

1. https://docs.cycling74.com/max7/vignettes/advanced_scheduler

2. https://docs.cycling74.com/max7/tutorials/04_mspaudioio

1. https://docs.cycling74.com/max7/vignettes/advanced_scheduler
2. https://docs.cycling74.com/max7/tutorials/04_mspaudioio

Thanks! I forgot the "Poll Throttle" option mentioned in your first link. It seemed that processing 20 high priority events at a time could have caused the issue. I tried setting this all the way down to 1 (interestingly 0 is also an option, but this stops the scheduler entirely), and unfortunately there was no effect. While I don't have DSP running, I tried checking the Audio Interrupt box and even adding a little dac~->adc~ section, but it didn't help.

Anyway since i no longer use the fast clock for anything but taking timestamps of incoming events, I'm going to try some hacks to read internal system times, but I wish I had a much better idea of why I'm up against this 20ms issue in Max itself.

Thanks!  I forgot the "Poll Throttle" option mentioned in your first link. It seemed that processing 20 high priority events at a time could have caused the issue.  I tried setting this all the way down to 1 (interestingly 0 is also an option, but this stops the scheduler entirely), and unfortunately there was no effect. While I don't have DSP running, I tried checking the Audio Interrupt box and even adding a little dac~->adc~ section, but it didn't help.

Anyway since i no longer use the fast clock for anything but taking timestamps of incoming events, I'm going to try some hacks to read internal system times, but I wish I had a much better idea of why I'm up against this 20ms issue in Max itself.
 

Weird. I haven’t programmed externals with clocks myself, so can’t validate your code examples. Just curious, do the normal objects bundled with Max work fine with small delays, etc.?

Hi, you must have figured it out by now, but no hacks needed to read internal system time, you can read Max's internal time directly with `clock_getftime`.

However, it seems to get out of sync with sample time when the DSP graph is changed, but that's a different issue...

Hi, you must have figured it out by now, but no hacks needed to read internal system time, you can read Max's internal time directly with `clock_getftime`.
However, it seems to get out of sync with sample time when the DSP graph is changed, but that's a different issue...


Sloppy clocks with clock_fdelay