Florent Ghys

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

 there are still a few things that are unclear to me:

- can I assume that integers coming out of transport's second outlet (beats) are in the high priority thread?

- if I work in Audio In Interrupt and these integers are in high priority, am I correct to assume that their precision is related to my signal vector size?

- is the high priority thread object-to-object based? For example [toggle > metro > counter > dial] would be [low / high / low / low]? Or does it mean the whole chain is in high priority?

- what is the best way to trigger a max message and be sure it's in high priority? Add delay after each object? Add delay only once?

- are the four following examples similar? And am I correct in the priority levels? `

- Are [snapshot~ 1 > speedlim 200], [snapshot~ 200} and {qmetro 200 > snapshot~] equivalent in terms of data rate reduction? 


I would really appreciate some insight from the Max gurus here.

Sorry if those questions sound obvious for you guys, they are definitely not to me.

After reading this great article https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/ there are still a few things that are unclear to me:
- can I assume that integers coming out of transport's second outlet (beats) are in the high priority thread?
- if I work in Audio In Interrupt and these integers are in high priority, am I correct to assume that their precision is related to my signal vector size?
- is the high priority thread object-to-object based? For example [toggle > metro > counter > dial] would be [low / high / low / low]? Or does it mean the whole chain is in high priority?
- what is the best way to trigger a max message and be sure it's in high priority? Add delay after each object? Add delay only once?
- are the four following examples similar? And am I correct in the priority levels?  `

I would really appreciate some insight from the Max gurus here.
Sorry if those questions sound obvious for you guys, they are definitely not to me.
thanks
Florent


keeping-max-messages-in-high-priority-thread

I'll try to answer some of your questions:

can I assume that integers coming out of transport’s second outlet (beats) are in the high priority thread?"

if I work in Audio In Interrupt and these integers are in high priority, am I correct to assume that their precision is related to my signal vector size?"

is the high priority thread object-to-object based? For example [toggle > metro > counter > dial] would be [low / high / low / low]? Or does it mean the whole chain is in high priority?

toggle, if clicked, outputs a message in the main (low priority) thread.

metro outputs messages in the scheduler (high priority) thread.

counter outputs numbers in the thread of the messages it receives. So, in this example, it will output messages in the scheduler thread. This is the general rule for most Max objects. Indeed, under the hood, mouse and keyboard actions translate as messages coming in the main thread, so the toggle above is no exception. On the other hand, there are exceptions.

dial follows the same rule: in this example, since it receives numbers in the scheduler thread, it will also output them in the scheduler thread. On the other hand, all the Max objects are drawn in the main thread, but this doesn't affect the way they output messages.

what is the best way to trigger a max message and be sure it’s in high priority? Add delay after each object? Add delay only once?

All the MIDI interactions happen in the scheduler thread

All the mouse and keyboard interactions happen in the main thread

All the file operations happen in the main thread, so if for any reason you need a message triggered by a file operation to be moved to the scheduler thread, you will need to delay it. Also, file operations are moved at the tail of the main thread queue, as with deferlow.

All the messages related to the audio thread (see e.g. snapshot~, edge~) happen in the scheduler thread

Some specific objects (defer, deferlow, jit.qball, qmetro -- am I forgetting something?), and all the Jitter objects, always output messages in the main thread.

So, there is no simple answer. Still, I’d say that in general you don’t need a delay after each object.

are the four following examples similar? And am I correct in the priority levels?

No. All the final bangs happen in the scheduler thread -- which, since you switch SIAI on, coincides with the audio thread. Still, I don’t think that the comment “High priority” beside the phasor~ makes much sense.

Are [snapshot~ 1 > speedlim 200], [snapshot~ 200} and {qmetro 200 > snapshot~] equivalent in terms of data rate reduction?

It seems to me that, although the results can be pretty similar, or probably identical in most cases, the three examples are not strictly equivalent. But I’d have to give them more thought...

Hi Florent.
I'll try to answer some of your questions:

can I assume that integers coming out of transport’s second outlet (beats) are in the high priority thread?"


if I work in Audio In Interrupt and these integers are in high priority, am I correct to assume that their precision is related to my signal vector size?"


is the high priority thread object-to-object based? For example [toggle > metro > counter > dial] would be [low / high / low / low]? Or does it mean the whole chain is in high priority?


toggle, if clicked, outputs a message in the main (low priority) thread.
metro outputs messages in the scheduler (high priority) thread.
counter outputs numbers in the thread of the messages it receives. So, in this example, it will output messages in the scheduler thread. This is the general rule for most Max objects. Indeed, under the hood, mouse and keyboard actions translate as messages coming in the main thread, so the toggle above is no exception. On the other hand, there are exceptions.
dial follows the same rule: in this example, since it receives numbers in the scheduler thread, it will also output them in the scheduler thread. On the other hand, all the Max objects are drawn in the main thread, but this doesn't affect the way they output messages.

what is the best way to trigger a max message and be sure it’s in high priority? Add delay after each object? Add delay only once?


See above, and also keep in mind that:
All the MIDI interactions happen in the scheduler thread
All the mouse and keyboard interactions happen in the main thread
All the file operations happen in the main thread, so if for any reason you need a message triggered by a file operation to be moved to the scheduler thread, you will need to delay it. Also, file operations are moved at the tail of the main thread queue, as with deferlow.
All the messages related to the audio thread (see e.g. snapshot~, edge~) happen in the scheduler thread
Some specific objects (defer, deferlow, jit.qball, qmetro -- am I forgetting something?), and all the Jitter objects, always output messages in the main thread.
So, there is no simple answer. Still, I’d say that in general you don’t need a delay after each object.

are the four following examples similar? And am I correct in the priority levels?


Are [snapshot~ 1 > speedlim 200], [snapshot~ 200} and {qmetro 200 > snapshot~] equivalent in terms of data rate reduction?


everything begins to make so much sense now

I'd be interested in knowing what the differences between the three snapshot~ examples in my last point are.

(and thanks so much Andrea for your work on bach, it's so awesome!! I'm using it all the time)

thank you so much Andrea!
everything begins to make so much sense now

(and thanks so much Andrea for your work on bach, it's so awesome!! I'm using it all the time)


keeping max messages in high priority thread