order of execution
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 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.
Thank you.
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.
( with thanks to Mikey Z )
Yeah, I saw this one on facebook.
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:
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:
join is also exempt:
I prefer join to my previous, deferlow, workaround. In fact, I might upgrade my teaching to prefer join over pack/pak
More funny stuff?
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...
@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.