I did that before (using print)
so ok the blue block us in sync with the pak output
so why pack behave this way
here is an improved version with more print
at some point pak output don't reflect the inputs
The issue is that pak is an exceptional object since all inlets produce result. If one action triggers all inlets of pak, which again triggers the ui object from which the original message originates, basically you are programming a cascade of events. That this does not create a stack overflow is mere chance. As Chris said:
> I'm more interested in why this doesn't cause a stack overflow.
Exactly the same behavior can be created with the bondo object, which is as exceptional as pak. You have programmed something which is not allowed, which is to retrigger the object before it has finished producing result on all its outputs. I remember to have run in similar situations with grab and zl. It is not a bug, but a programming mistake.
But to restate Andrew's question: why are you patching it like this? For sure there are solutions to what you try to achieve.
I am sorry, but I have to disagree
if you look at my last patch here
using pack and triggers it works
so it clearly show that pak misbehave (and you agree).
That this bug is not a priority I can understand,
i will still argue that the time lost by different users on this worth a fix.
jsui and preset force to do some tricky stuff to wrap then around with "real max object". And doing this without pak can make it really hairy.
So the only way is to use pattr (with getvalue() of and setvalueof()
with jsuiand not preset.
In this case the trouble is that all the state of the jsui is one big chunk of data and that you can't select with the client window what you select. It also make the storage window data unreadable.
I had a better solution using multislider
but there is no options there to "isolate" the sliders,
so when you use one slider you can't change accidently the neighbors.
for bug to bug, lack of feature to lack of feature, I have to find custon solutions, which can be fun and challenging but not efficient in terms of production.
I guess my main concern is infact
that the documentation is not complete enough,
in particular some golden rules (as the one you just stated) should make a chapter,
While there are clearly things that pak does differently than the equivalent pack / trigger combo, I would like to emphasize something Andrew said: " You're advised to stay away from trying to patch Max recursively…"
The sort of recursion that you have in your patch is bad practice for programming in Max. The result is usually a stack overflow, but sometimes a crash. Recursion will continue to bite you in places where I assume you would rather not be bitten.