Pvdn

I was hunting down some strange order behaviour in a patch i am working on, and after stripping everything away i found out that when there is a bpatcher involved, right-to-left order doesnt work the way i thought it would.

In this screenshot, the left print is triggered first, and the one inside the bpatcher last: 

Is this intended behaviour? Can't i rely on right-to-left order when bpatchers are involved? I am confused...

In this screenshot, the left print is triggered first, and  the one inside the bpatcher last: http://i.imgur.com/oldpnzq.png 

I was hunting down some strange order behaviour in a patch i am working on, and after stripping everything away i found out that when there 

right-to-left-order-and-bpatchers

Very Interesing! didn't know that either.

But in my opinion I wouldn't rely on right/left order in a case where the order is important and would make sure it works the way I want to using something like a [t] (trigger) object or defer etc.

Very Interesing! didn't know that either.

But in my opinion I wouldn't rely on right/left order in a case where the order is important and would make sure it works the way I want to using something like a [t] (trigger) object or defer etc.


But order is important nearly everywhere, that would result in adding *a lot* of trigger objects.

Yes, you're right, [t] might end up being the most current Max object in some patches: as soon as you need to rely on "right to left" ordering, you should systematically use a trigger object. Better for debugging and patch longevity.

Wow! This explains some very bizarre/obscure issues I've seen over the years, my patchers are VERY bpatcher intensive.

I just did a few experiments to verify this and even if you have multiple bpatchers to the right, the LEFT print still happens first. I used [cpuclock] objects to make sure it wasn't just a problem with [print] being deferred or something.

You can fix the problem by inserting a bang message just before the bpatcher (see http://imgur.com/a/mmmL3) which MAY make sense if you don't want to throw trigger objects absolutely everywhere. I personally love the right-to-left ordering (it's a visual language, make use of the 2-dimensional layout, right!) and am dismayed to discover this.

Wow!  This explains some very bizarre/obscure issues I've seen over the years, my patchers are VERY bpatcher intensive.

I just did a few experiments to verify this and even if you have multiple bpatchers to the right, the LEFT print still happens first.  I used [cpuclock]  objects to make sure it wasn't just a problem with [print] being deferred or something.

Maybe a simple bug that the position of the bpatcher patching rectangle is not calculated correctly.

I tried it on Max 5 as well and saw the same problem --- this issue has been around a long time. I hope they fix it but if they do, they'll probably have to include a preference that would allow the old behavior otherwise a lot of patchers will probably break

I tried it on Max 5 as well and saw the same problem --- this issue has been around a long time.  I hope they fix it but if they do, they'll probably have to include a preference that would allow the old behavior otherwise a lot of patchers will probably break

guys, i am not trying to be funny here (really) but this doesn't happen in max 4.

until now i haven seen it in 5/6/7 either. can it be that it only happens with GUI objects?

because what is the most strange part is that a trigger already fixes it!

There's nothing strange about the trigger fixing it (or just the extra "bang message for that matter). Remember that while the ordering goes right-to-left, execution is still depth first and since the 'bang' (or trigger) is connected ONLY to the bpatcher, there's no issue once you get that far.

There's nothing strange about the trigger fixing it (or just the extra "bang message for that matter). Remember that while the ordering goes right-to-left, execution is still depth first and since the 'bang' (or trigger) is  connected ONLY to the bpatcher, there's no issue once you get that far.

Hm, I think this is simply a bug. It results in counter-intuitive behavior.

This is what I see in the console after clicking 'world' twice:

Image 10.png

Obviously it is good practice to always use a trigger where order matters, but that doesn't mean that this unexpected behavior is okay.

Hm, I think this is simply a bug. It results in counter-intuitive behavior. 

This is what I see in the console after clicking 'world' twice:


It seems to be a bug related to bpatcher. works fine if it's a normal abstractions. When using the debugger it becomes visible that the right connection is not treated as it should.

max_right_left_bug.mp4

yes. one can easily forget that behind the curtains the bpatcher object fetches the data from the object connected to it, because we of course think in "data is sent from here to there". :)

There's nothing strange about the trigger fixing it (or just the extra  "bang message for that matter). Remember that while the ordering goes  right-to-left, execution is still depth first


yes. one can easily forget that behind the curtains the bpatcher object fetches the data from the object connected to it, because we of course think in "data is sent from here to there". :)


Right to left order and bpatchers