matteosistisette

I attach a simple patch where I sometimes get a behaviour I can't explain.

I (think I) make sure to do things in a certain order and it seems that they sometimes happen in reversed order, so I can't understand what I am doing wrong.

Please look at the attached patch: expected vs observed behaviour is detailed in the comments inside the patch, and the patch is extremely simplified.

The only explanation I can find is that when you send a message to a matrix (such as the output of another matrix, or a setall message) that is supposed to perform a write operation on that matrix, it is not guaranteed that this operation is atomically performed before any other message arrives to the same matrix. That is, if a second message arrives after the first one (obviously in the order of milliseconds after or less), the write operation of the second message MAY be performed before the write operation triggered by the first message.

It seems to me that it shouldn't be so... but that's what I am observing.....

Can anyone confirm my analysis? Or point out what's wrong in the patch?

In case this is correct, is there a way of ensuring "atomicity" of operations in the sense explained above (and in the patch)?

I can program in such a way to always ensure that max events (i.e. bangs, messages etc) are delivered in the order I need them to be delivered, but if I cannot trust that the operations they perform are then executed in the same order, well, programming is gonna become quite complicated ;)

If it is so, I'm sure a lot of people must have faced this "problem" and can suggest frameworks and techniques to make things easier.

Note that in the attached example, I may easily re-draw the black square at every frame when the big toggle is off, but I want to avoid unnecessary cpu-consuming operations such as keep refreshing matrix data that I know is not changing.

I can program in such a way to always ensure that max events (i.e. bangs, messages etc) are delivered in the order I need them to be delivered, but if I cannot trust that the operations they perform are then executed in the same order, well, programming is gonna become quite complicated ;)
If it is so, I'm sure a lot of people must have faced this "problem" and can suggest frameworks and techniques to make things easier.

Thanks in advance
bye
matteo sisti sette


writing-on-a-matrix-isnt-it-an-atomic-operation

If you are going to attach patches to the forums, please either paste it 

as text or create a .zip archive. The current binary format of max 

patches almost always gets corrupted in transfers.

Please also take a minute to read this page:

https://cycling74.com/twiki/bin/view/FAQs/BeginnersFAQ

Hello Matteo,
If you are going to attach patches to the forums, please either paste it 
as text or create a .zip archive.  The current binary format of max 
patches almost always gets corrupted in transfers.

Please also take a minute to read this page:
https://cycling74.com/twiki/bin/view/FAQs/BeginnersFAQ

Here's the same patch attached as a zip file

Adding a deferlow before the 1 X 1 matrix makes it reliable, as does using a

qmetro as the METROBANG driver. I run into this sort of problem many times.

On 7/27/07 5:08 AM, "matteo sisti sette" wrote:

> I attach a simple patch where I sometimes get a behaviour I can't explain.

> I (think I) make sure to do things in a certain order and it seems that they

> sometimes happen in reversed order, so I can't understand what I am doing

> Please look at the attached patch: expected vs observed behaviour is detailed

> in the comments inside the patch, and the patch is extremely simplified.

> The only explanation I can find is that when you send a message to a matrix

> (such as the output of another matrix, or a setall message) that is supposed

> to perform a write operation on that matrix, it is not guaranteed that this

> operation is atomically performed before any other message arrives to the same

> matrix. That is, if a second message arrives after the first one (obviously in

> the order of milliseconds after or less), the write operation of the second

> message MAY be performed before the write operation triggered by the first

> It seems to me that it shouldn't be so... but that's what I am observing.....

> Can anyone confirm my analysis? Or point out what's wrong in the patch?

> In case this is correct, is there a way of ensuring "atomicity" of operations

> in the sense explained above (and in the patch)?

> I can program in such a way to always ensure that max events (i.e. bangs,

> messages etc) are delivered in the order I need them to be delivered, but if I

> cannot trust that the operations they perform are then executed in the same

> order, well, programming is gonna become quite complicated ;)

> If it is so, I'm sure a lot of people must have faced this "problem" and can

> suggest frameworks and techniques to make things easier.

> Note that in the attached example, I may easily re-draw the black square at

> every frame when the big toggle is off, but I want to avoid unnecessary

> cpu-consuming operations such as keep refreshing matrix data that I know is

Adding a deferlow before the 1 X 1 matrix makes it reliable, as does using a
qmetro as the METROBANG driver.  I run into this sort of problem many times.

On 7/27/07 5:08 AM, "matteo sisti sette"  wrote:

> Hi,
>
> I attach a simple patch where I sometimes get a behaviour I can't explain.
>
> I (think I) make sure to do things in a certain order and it seems that they
> sometimes happen in reversed order, so I can't understand what I am doing
> wrong.
>
> Please look at the attached patch: expected vs observed behaviour is detailed
> in the comments inside the patch, and the patch is extremely simplified.
>
> The only explanation I can find is that when you send a message to a matrix
> (such as the output of another matrix, or a setall message) that is supposed
> to perform a write operation on that matrix, it is not guaranteed that this
> operation is atomically performed before any other message arrives to the same
> matrix. That is, if a second message arrives after the first one (obviously in
> the order of milliseconds after or less), the write operation of the second
> message MAY be performed before the write operation triggered by the first
> message.
>
> It seems to me that it shouldn't be so... but that's what I am observing.....
>
> Can anyone confirm my analysis? Or point out what's wrong in the patch?
>
> In case this is correct, is there a way of ensuring "atomicity" of operations
> in the sense explained above (and in the patch)?
>
> I can program in such a way to always ensure that max events (i.e. bangs,
> messages etc) are delivered in the order I need them to be delivered, but if I
> cannot trust that the operations they perform are then executed in the same
> order, well, programming is gonna become quite complicated ;)
> If it is so, I'm sure a lot of people must have faced this "problem" and can
> suggest frameworks and techniques to make things easier.
>
>
> Note that in the attached example, I may easily re-draw the black square at
> every frame when the big toggle is off, but I want to avoid unnecessary
> cpu-consuming operations such as keep refreshing matrix data that I know is
> not changing.
>
>
> Thanks in advance
> bye
> matteo sisti sette

May you please explain me a little more how this trick works?

(I understand how to do it, but I'm confused about why it fixes the problem)

I have read the help about qmetro, deferlow, jit.qball but I am still a bit confused.

May you please explain me a little more how this trick works?
(I understand how to do it, but I'm confused about why it fixes the problem)

By the way, your second suggested solution works, but the first one doesn't.

I've understood a little more by reading "Event Priority in Max (scheduler vs queue) 

https://cycling74.com/story/2005/5/2/133649/9742

However, that article says that when "Overdrive" is not activated, there is no high priority thread at all.

So, since I have not enabled Overdrive (and I can see it is disabled), how is it possible that there is any difference between using metro and using qmetro??

I've understood a little more by reading "Event Priority in Max (scheduler vs queue) https://cycling74.com/story/2005/5/2/133649/9742

However, that article says that when "Overdrive" is not activated, there is no high priority thread at all.
So, since I have not enabled Overdrive (and I can see it is disabled), how is it possible that there is any difference between using metro and using qmetro??


writing on a matrix: isn't it an atomic operation??