defer - deferlow

let´s start with defer, which is relatively simple.

if you are in overdrive and connect

[metro]
[defer]

metro will output its data into the high priority thread of max runtime, but after defer it will be moved back to the main thread again. (to do the opposite you can use pipe 0. or del 0.)

so for example i sometimes do this:

[sequencer clocked, timecritical data in overdrive]
/ /
[defer] [complicated math for audio DSP]
/
[complicated math for GUI object]

to free up some space in the scheduler thread.

some other things are more on a trial and error basis. for example defer and deferlow sometimes fix issues with loading files on patch init or queueing bugs around [bpatcher]

there is a good article somewhere here about all this stuff.

One source of information on the scheduler vs low-priority threads:
https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/
You might also have a look at the cousin object [jit.qball].
When you use defer objects, keep in mind this possible side effect: a carefully sequenced [t b b i b] will execute correctly in the high priority thread when triggered by, say, a MIDI event; now, if you connect a [defer]/[deferlow] on the rightmost outlet, then the order of execution will not be guarranteed.

@roman as I understand it, defer is used to switch from high priority thread to main thread, and pipe 0. or del 0. to do the reverse process. But why is the complicated math for audio DSPs (I imagine processes using FFT) left out of the high priority thread? Couldn't there be glitch problems in this case?

These are three different threads:
- the audio thread (MSP) is generally the highest priority
- the high priority Max events thread (things triggered by MIDI, [metro], etc.)
- the low priority Max events thread (things triggered by the mouse, [qmetro], etc.)
On this topic, the discussion I linked above is excellent.

The article Jean-Francois links to explains this, but the other wrinkle is that if you select "Audio Interrupt" in the audio status settings, then the high priority thread *is* the audio thread (thus there are only two threads), and that thread alternates between handing events on the high priority event queue and rendering the dsp vector. This may or may not be what you want, so worth testing out.

The article Jean-Francois links to explains this, but the other wrinkle is that if you select "Audio Interrupt" in the audio status settings, then the high priority thread is the audio thread (thus there are only two threads), and that thread alternates between handing events on the high priority event queue and rendering the dsp vector.

How does deferlow and defer differ in the case of the two threads only? Do they put events at the tail (for the former) and the front (for the latter) of the high priority thread?

...of the main thread.

Aha, so there's only the main thread and the audio thread?