lvdw

Probably a known thing / some historical issue. In any case, I'd like to learn more about this behaviour:

message

button

pack

Why doesn't it say 1 -333 in all message boxes after clicking the upper message box?

To be clear: I do understand right to left order and all that. Posting it in the Facebook Max/MSP group didn't give me a satisfying answer.

Why doesn't it say 1 -333 in all message boxes after clicking the upper message box?
To be clear: I do understand right to left order and all that. Posting it in the Facebook Max/MSP group didn't give me a satisfying answer.

Probably a known thing / some historical issue. In any case, I'd like to learn more about this behaviour:
 
Why doesn't it say 1 -333 in all

order-of-execution

it shows -333 for the very first time in the leftmost messagebox, but you cant see it because it is overwritten with 99 within less than 1 millisecond.

after that the -333 is no longer present in the pack object. or from where do you expect it to come from, after you willingly replaced it? :)

time for you to dive into the debugger menu!

Yes it is an historical behaviour of Max which will not get changed.

The pack object uses a particular method to write its output ( outlet_list)

What you are seeing here is the contents of the output getting rewritten while outlet_list is in use.

It is a counter-intuitive behaviour; it breaks the illusion that data is flowing down these patch cords. If Max was a new product, I don't think it would be made like this. But, I understand and agree that it shouldn't change. First, I've never ever seen this in 25 years of patching. Second, somebody might be using this as a feature.

Also, passing around pointers is more efficient than passing around values. I can see why Max was written this way in the 80's. An implementation with a more typical behaviour would involve making a copy of the list that pack would output, and passing around a pointer to that copy. Skipping that copy step is a bit of efficiency that was probably meaningful in the '80s.

FWIW, my favourite Max code smell, deferlow, gives the more expected result:

It is a counter-intuitive behaviour; it breaks the illusion that data is flowing down these patch cords.  If Max was a new product, I don't think it would be made like this.  But, I understand and agree that  it shouldn't change. First, I've never ever seen this in 25 years of patching. Second, somebody might be using this as a feature. 

Roman, *you* should follow this through in the debugger. You'll see there's only one message per output.

Thanks everyone, I guess that clears it all up. Very nice. (Actually, I think I must have encountered this before, either with my own patching or in someone else's thread or topic or story. But maybe it's some deja vu.)

Raises one more question: are there more objects that behave like this? I.e., where you can't just assume the right-to-left order functions as you would expect?

I suspect that any object that uses the same outlet_list() method as pack and trigger could be induced to behave like this.

It seems like zl reg behaves differently than pack:

, workaround. In fact, I might upgrade my teaching to prefer 

I prefer join to my previous, deferlow, workaround. In fact, I might upgrade my teaching to prefer join over pack/pak

I would expect the print objects to first output 33 after 1 sec and another second later a list (22 11). And why not? After all, the timeframe argument of thresh prevents a stack overflow. And: adding a [pipe 0] solves it:

How old is thresh? Never used it for some real stuff, just toying around with some weird objects to see if there's more...

there must be something i am not seeing. in the given example i am getting -333 for the trigger, and what the pack does (e3specially to print) seems to be irrelevant. because from the viewpoint of the trigger this pack patch behaves just like a number patch would, too.

pack-anomaly.png

@mzed: 
there must be something i am not seeing. in the given example i am getting -333 for the trigger, and what the pack does (e3specially to print) seems to be irrelevant. because from the viewpoint of the trigger this pack patch behaves just like a number patch would, too.


oh right, i ignored the first three outlets of the trigger.

order of execution