Iain Duncan

Hi devs, I'm hoping someone can confirm for me that this is correct, (or correct me!) before I go and say misleading things in documentation and videos. :-)

My Scheme-for-Max external is written in C, and does not yet have functions to force evaluation into specific threads (I'll get there later). So my understanding of this is that that means any C code in the external will run in whatever thread the message it is triggered by is in. Meaning, that if overdrive is on, messages:

- from the GUI will execute in low-priority thread (i.e. originating from clicking or moving gui elements)

- from a metronome will be in the high priority thread (i.e. bangs from a clock)

- from midi input will be high priority thread (i.e. notes, fader moves etc)

- messages triggered from audio activity used to trigger events will be high priority (i.e. clocking off a phasor using edge detection

Further, my understanding is that in current versions of Max, there is no difference in priority and thus timing stability between the metronome and clocking off a phasor (if in overdrive with the audio engine on)

If someone who really knows this stuff can verify that this is right, that would be super helpful.

My Scheme-for-Max external is written in C, and does not yet have functions to force evaluation into specific threads (I'll get there later). So my understanding of this is that that means any C code in the external will run in whatever thread the message it is triggered by is in.  Meaning, that if overdrive is on, messages:

- from the GUI will execute in low-priority thread (i.e. originating from clicking or moving gui elements)
- from a metronome will be in the high priority thread (i.e. bangs from a clock)
- from midi input will be high priority thread (i.e. notes, fader moves etc)
- messages triggered from audio activity used to trigger events will be high priority (i.e. clocking off a phasor using edge detection

Further, my understanding is that in current versions of Max, there is no difference in priority and thus timing stability between the metronome and clocking off a phasor (if in overdrive with the audio engine on)

If someone who really knows this stuff can verify that this is right, that would be super helpful.
thanks! 
iain

Hi devs, I'm hoping someone can confirm for me that this is correct, (or correct me!) before I go and say misleading things in documentation

please-confirm-my-understanding-of-thread-priority-for-externals

ya, this much is true if you haven't coded deferral into your external(but in the rest of your description, it might get confusing if you're not specific, for example: "from a metronome will be in the high priority thread (i.e. bangs from a clock)"... technically 'qmetro' is a metronome(outputting bangs from a clock), but it's deferred to lower priority, and 'metro' itself has an "@defer" attribute which can defer it to work like 'qmetro'...)

so just my suggestion(as you have the overall idea correct, but if you try to draw out case-by-case, it might be difficult to be fully comprehensive in your own documentation), you could just link to something cycling74 already wrote about it like this:

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue

(the video Luigi linked you to in another thread is also linked in the comments at the end of that article, too)

then again, if you're just writing an external max users will be patching with(and not encasing it within an app you want to distribute separate from mentions of max itself), just the sentence mentioning there's no current deferral code within your external so [the above single-line sentence i quoted of yours] is true, might be enough(max users should learn those details from the docs already provided anyways).

that means any C code in the external will run in whatever thread the message it is triggered by is in

ya, this much is true if you haven't coded deferral into your external(but in the rest of your description, it might get confusing if you're not specific, for example: "from a metronome will be in the high priority thread (i.e. bangs from a clock)"... technically 'qmetro' is a metronome(outputting bangs from a clock), but it's deferred to lower priority, and 'metro' itself has an "@defer" attribute which can defer it to work like 'qmetro'...)
so just my suggestion(as you have the overall idea correct, but if you try to draw out case-by-case, it might be difficult to be fully comprehensive in your own documentation), you could just link to something cycling74 already wrote about it like this:
https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue

(the video Luigi linked you to in another thread is also linked in the comments at the end of that article, too)

then again, if you're just writing an external max users will be patching with(and not encasing it within an app you want to distribute separate from mentions of max itself), just the sentence mentioning there's no current deferral code within your external so [the above single-line sentence i quoted of yours] is true, might be enough(max users should learn those details from the docs already provided anyways).

threads in Max have been discussed at great length on this forum and there are quite a few documents online that discuss/explain threads specifically to the Max environment.

The document the Raja linked is a perfect example.

However - at the risk of sounding redundant - here is how I think about the threading model in Max/MSP:

the Max environment allows 3 execution modes:

1) Overdrive ON - Scheduler in Audio Interrupt OFF:

2) Overdrive ON - Scheduler in Audio Interrupt ON

3) Overdrive OFF - Scheduler in Audio Interrupt OFF

For the sake of completeness, there is a 4th hypothetical mode:

4) Overdrive OFF - Scheduler in Audio Interrupt ON

• DSP thread + high and low priority threads

In the 4th hypothetical mode everything would run in the same thread and - as a matter of fact - Cycling74 disables this mode completely.

A well written external object must work flawlessly in all 3 execution modes described above.

threads in Max have been discussed at great length on this forum and there are quite a few documents online that discuss/explain threads specifically to the Max environment.
The document the Raja linked is a perfect example.

However - at the risk of sounding redundant - here is how I think about the threading model in Max/MSP:

1) Overdrive ON - Scheduler in Audio Interrupt OFF:
   • DSP thread
   • High priority thread
   • Low priority thread

2) Overdrive ON - Scheduler in Audio Interrupt ON
   • DSP + high priority thread
   • Low priority thread

3) Overdrive OFF - Scheduler in Audio Interrupt OFF
   • DSP thread
   • High and low priority threads

4) Overdrive OFF - Scheduler in Audio Interrupt ON
    • DSP thread + high and low priority threads

A well written external object must work flawlessly in all 3 execution modes described above.
Hope this helps.

Thanks guys. I had seen the article Raja linked to but wasn't sure if that was still accurate given when it was written. I appreciate the input. Luigi, that's table is really helpful.

Thanks guys.  I had seen the article Raja linked to but wasn't sure if that was still accurate given when it was written. I appreciate the input. Luigi, that's table is really helpful.

Confirmation wanted: thread priority and event timing for externals...