lower than 1ms only has an effect on time resolution if you also lower the vectorsize of the DSP. for 0.5ms you would need to set audio to 16 samples.

My understanding was that this only true if Audio in Interrupt is on the preferences, otherwise the scheduler is not locked to the dsp vector processing block. Or is it always the case that it takes at least a vector of samples between scheduling passes? If any C74 devs are available to clarify, that would be lovely.

That said, it would still be useful when using Max for events only, as I could happily use a lower audio vector size.

ya, that's how i understood it, too(and 16 samples for 0.5ms implies only a sampling-rate of 32kHz?.... but in any case, this might be true if audio was on, overdrive was on, and 'in-audio-interrupt' was on)

decreasing the scheduler interval might not do anything: every tick of the scheduler a certain number of events are polled. if you decrease the interval, the scheduler might not be able to poll all the events desired in one tick(this is the "poll throttle" setting in preferences... and even if i got the description of "poll throttle" wrong, and it refers to lower-priority, which i don't think it does because 'queue throttle' is described as referring to the lower-priority queue, there is still some mechanism by which events will be "polled" each tick of the scheduler...) therefore, even if you reduce the scheduler 'interval', the amount of events it can still 'poll' in one tick of that scheduler might suffer(depends on CPU... i think the way they devved it so far, this is as much as most machines can handle... but i imagine in the ongoing future, they could revisit this and see if it's possible to speed up somehow)..

My thought, (could be off base!), is that allowing the scheduler to run more frequently will allow me to effectively give more processing power to the scheduler thread vs audio processing, which is what I'm after for my use cases. 1 ms is a long time in threading terms, and the issues I'm experiencing are definitely when the scheduler can't keep up. I presume that running it both more frequently and with a higher number of events handled per pass will help here. In my case, I'm trying to do high resolution automation of message data, with the audio mostly handled elsewhere.

At any rate, I'm building up a suite of load testing patches for Scheme For Max, so I should be able to get more definitive results soon.

not off base at all, i like the request, it's a good one(1ms is a long time in threading terms, but priority-assurance of 40 events(or whatever value you set the 'poll throttle' to) within that 1ms, coupled with lower-priority queue-handling beyond that, plus all the complexity that system of prioritizing entails, will require that it's not just the processing 'speed'(/'interval') of the scheduler, but also the processing 'power' that needs to improve altogether).

"ya, that's how i understood it, too(and 16 samples for 0.5ms implies only a sampling-rate of 32kHz?... " no, but 32 samples is not enough for 0.5 ms (and you cant use 25 samples^^) btw. i am sure there are scenarios where you can avoid enabling scheduler in audio interrupt. but generally you are using the scheduler because you want things to be as exact as possible, i.e. you dont want to delay "note on messages" because of too much "lcd formatting". if you now allow messages at scheduler rate to arrive later than with the first sampe of the next vector, you introduce huge jitter into your musical events control and it is questionable if you would be better be off with scheduler turned off. (?) but i have never actually tried it. my interrupt is always on, i love enabling things.

One is using the scheduler for *any* messages in the high priority thread, all the time - that's what it does. If you are using a patcher with high loads of messages in the high priority thread, you can easily be in situations where 1-2 ms of jitter of the scheduler thread is not noticeable, but Audio Interrupt will create audio dropouts. You may not experiences this, but I do routinely. We all use Max differently...