to_the_sun

Today I spent contemplating the existential questions of Max. It began when I was informed that send and receive use the low priority thread. At this point I became fearful, wondering if, under extreme circumstances where CPU is pushed to its limit, messages being [send]ed about might begin to falter in their order of execution when competing against messages traveling through corded connections. In order to allay my fears I began to mess around with a test patch

I wanted to see if the high-priority trigger object would ever fire its left outlet before its right outlet had finished its responsible and correct depth first execution, even with it slated to low priority and 10 million uzi bullets in the air. Then I realized that the uzi object itself begins a low priority event and therefore the send and receive were superfluous. So I got to thinking that low priority events really begin all the time and don't ever seem to falter in their order in the face of high priority, the way say, deferlow does and is meant to.

Can I be 100% certain that order of execution will be maintained even when sending messages through send and receive? 

How exactly is it then that the creation of a low priority event is handled in the midst of a high priority chain of events, that makes it low priority when it seems to execute immediately, before the overarching high priority event has gone any further?

- I did notice with my test patch that sending the uzi bullets into a send took close to 3 times longer. Why is this? Is it because the uzi creates a single new event with 10 million items in it, whereas the send multiplies that event into 10 million individual events that each require a signal vector to their own or something like that? So how does this compare with deferlow then, which if the uzi is shot into it, will cause RAM usage to rocket to multiple gigs, before it begins to slowly taper off and maybe 45 minutes later Max will come back to its senses?

- Can I be 100% certain that order of execution will be maintained even when sending messages through send and receive?  How exactly is it then that the creation of a low priority event is handled in the midst of a high priority chain of events, that makes it low priority when it seems to execute immediately, before the overarching high priority event has gone any further?

- I did notice with my test patch that sending the uzi bullets into a send took close to 3 times longer. Why is this? Is it because the uzi creates a single new event with 10 million items in it, whereas the send multiplies that event into 10 million individual events that each require a signal vector to their own or something like that? So how does this compare with deferlow then, which if the uzi is shot into it, will cause RAM usage to rocket to multiple gigs, before it begins to slowly taper off and maybe 45 minutes later Max will come back to its senses?


sr-use-the-low-priority-thread-the-fear-and-other-priority-questions

Really, I think that using send/receive doesn't change anything to the priority level of your messages. I'm not sure you got a reliable piece of information about s/r happening in low priority. I'm pretty sure the order of events will always be kept, the behavior being "similar" to using patch cords. I hope heavy send/receive users will confirm.

Each uzi bullet is an individual event: I'm not surprised that the s/r example takes far more time.

Thanks for the remark on the RAM usage with shooting uzi bullets in a [deferlow]: beautiful indeed! I would have expected the old bullets to quickly vanish, to be replaced by a most recent one. I don't have 45 minutes right now to wait for something printing in the Max window, will have to come back to this one....

Hi,
Really, I think that using send/receive doesn't change anything to the priority level of your messages. I'm not sure you got a reliable piece of information about s/r happening in low priority. I'm pretty sure the order of events will always be kept, the behavior being "similar" to using patch cords. I hope heavy send/receive users will confirm.

Thanks for the remark on the RAM usage with shooting uzi bullets in a [deferlow]: beautiful indeed! I would have expected the old bullets to quickly vanish, to be replaced by a most recent one. I don't have 45 minutes right now to wait for something printing in the Max window, will have to come back to this one....


I think there is one important difference though : I may be wrong but I think I 've read or heard that the right to left and bottom to top order doesn't apply for s / r which send and receive according to their order of creation. This is easy to verify...

I think there is one important difference though : I may be wrong but I think I 've read or heard that the right to left  and bottom to top order doesn't apply for s / r which send and receive according to their order of creation. This is easy to verify...


It was a certain Ronen Peri who mentioned it, over in the Max/MSP group on Facebook

https://www.facebook.com/groups/2209224391/10153906313309392/?notif_t=group_comment_reply

The general answer I've always gotten to my 1st question does seem to be (a wary), "you don't have to worry about order using send and receive" and I'm inclined to believe it myself, but that leaves only 2 possibilities as I see it. Either send and receive (or uzi for that matter) 

 actually operate on low priority and/or don't even create new events at all, or they do, but there's a discrepancy to be made about how low and high priority events operate. Like maybe the only difference between them is that a

high priority event will interrupt low priority ones, whereas a low priority event won't interrupt anything, but also won't be interrupted itself by already-existing overarching events, whatever their priority.

Each uzi bullet is an individual event: I’m not surprised that the s/r example takes far more time.

I was thinking that maybe the only reason it takes about 2.5 times as long is simply that each bullet has to pass through 2 extra objects. Kind of makes sense doesn't it?

I think there is one important difference though : I may be wrong but I think I ‘ve read or heard that the right to left and bottom to top order doesn’t apply for s / r which send and receive according to their order of creation.

Indeed it is true that with multiple receive objects of the same name, their order of message release is not particularly predictable, if that's what you're referring to, but this does not disturb me. I had also always assumed it would instead be determined by their order of creation, but of course you wouldn't want to write your code depending on something like that.

The general answer I've always gotten to my 1st question does seem to be (a wary), "you don't have to worry about order using send and receive" and I'm inclined to believe it myself, but that leaves only 2 possibilities as I see it. Either send and receive (or uzi for that matter)  don't actually operate on low priority and/or don't even create new events at all, or they do, but there's a discrepancy to be made about how low and high priority events operate. Like maybe the only difference between them is that a new  high priority event will interrupt low priority ones, whereas a low priority event won't interrupt anything, but also won't be interrupted itself by already-existing overarching events, whatever their priority.

I think there is one important difference though : I may be wrong but I think I ‘ve read or heard that the right to left and bottom to top order doesn’t apply for s / r which send and receive according to their order of creation. 

Indeed it is true that with multiple receive objects of the same name, their order of message release is not particularly predictable, if that's what you're referring to, but this does not disturb me. I had also always assumed it would instead be determined by their order of creation, but of course you wouldn't want to write your code depending on something like that.


I've been reading and rereading this article

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

but I still have my questions about how the whole process works. I wish there was a comprehensive list of everything that could possibly generate a new event. I'm really starting to doubt that things like uzi and send and receive actually do create new events.

when i recall right, thre was a bug in v7 and/or max4live with that. normally stuff will stay in its thread.

Either send and receive (or uzi for that matter) don’t actually operate on low priority

I'm sure they indeed operate in high priority.

maybe the only reason it takes about 2.5 times as long is simply that each bullet has to pass through 2 extra objects. Kind of makes sense doesn’t it?

 I'm sure they indeed operate in high priority.

Thanks everyone for your feedback. I can say that my fears have been assuaged and my understanding of how priority works has been reaffirmed. My understanding being that objects like send, receive and uzi do not create new events and so cannot be said to have a certain priority; really it's only events that have priority and objects, though they may create new events, operate with the priority of the event of which they are a part (for example whether their section of code was triggered by a mouse click versus a metro bang). Do I have it right?

To begin a new tangent, Raja mentions the latency involved using send and receive between Max for Live devices. I assume that this latency doesn't mean that everything in the sending device pauses and is on hold until the other device receives its message, so does this mean that, in this case, a new event 

 created when the receive spits out its message? I suppose it must, as I'm assuming that each device has its own distinct high and low priority threads. Is this correct?

To begin a new tangent, Raja mentions the latency involved using send and receive between Max for Live devices. I assume that this latency doesn't mean that everything in the sending device pauses and is on hold until the other device receives its message, so does this mean that, in this case, a new event  is created when the receive spits out its message? I suppose it must, as I'm assuming that each device has its own distinct high and low priority threads. Is this correct?


I read again the "event priority" article you mentioned, I had not read it for a while. I agree with you: send/receive do not create new events, not uzi either. The priority of an event going through s/r is never changed. Few object have the power to change the priority of an event going through it (deferlow is one of them).

When it comes to communicating within Live, things might be different... Let the Live experts speak!

I read again the "event priority" article you mentioned, I had not read it for a while. I agree with you: send/receive do not create new events, not uzi either. The priority of an event going through s/r is never changed. Few object have the power to change the priority of an event going through it (deferlow is one of them).
When it comes to communicating within Live, things might be different... Let the Live experts speak!


s/r use the low priority thread!?! : the fear and other priority questions