is this a bug
or can somebody explain me why the blue message is not updated correctly when using the second slider
I’m more interested in why this doesn’t cause a stack overflow.
wrong inlet?
I figure it’s the cascaded trigger objects which are somehow preventing the overflow.
there is no stack overflow because of the gate and
the trigger [t 1 b 0]
it open the loop / propagate / then close it again
Andrew your solution make it work
but there is no overflow in the original graph
it would be a bug in the protection from overflow ?
The blue message does update correctly, but not to what you expect it should update to. Don’t let yourself be fooled by what you see. Try to explain what is printed in these patches:
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
so nobody knows
a refined case with a pak and a pack strategy
This works too
Out of curiosity – why are you patching it like this?
-A
`
OK EJ tells me it’s the pak object playing up in a recursive situation.
You should work around it.
-A
just for clarity
you mean there is a bug in pak ?
would it be corrected ?
If you replace slider by float boxes the problem is the same.
Thanks Maa
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.
The behaviour of the pak object is clearly problematic in the situation you have going here, but it’s not considered a bug in the sense that we’re going to do anything about it any time soon.
You’re advised to stay away from trying to patch Max recursively, or use other workarounds.
-A
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,
Maa
Maa
As we already discussed privately, the simpliest way I found to achieve what you want is to use [sw], really helping in looping situations.
If I understood correctly, your only problem is that jsui doesn’t expose its attributes separately to pattrstorage, which, I agree, could be a good feature request.
I’m pretty sure that if you had explained this problem directly at the top of the thread,
you would already have more solutions than you expected.
Instead everyone is scratching is head : ok, maybe there’s a bug, but what is he trying to do ? :)
léo
This one is even more elegant
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.