is this a bug

    Apr 12 2011 | 2:34 am
    or can somebody explain me why the blue message is not updated correctly when using the second slider

    • Apr 12 2011 | 4:27 am
      I'm more interested in why this doesn't cause a stack overflow.
    • Apr 12 2011 | 5:11 am
      wrong inlet?
    • Apr 12 2011 | 5:15 am
      I figure it's the cascaded trigger objects which are somehow preventing the overflow.
    • Apr 12 2011 | 9:15 am
      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 ?
    • Apr 12 2011 | 11:03 am
      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:
    • Apr 12 2011 | 2:08 pm
      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
    • Apr 12 2011 | 9:54 pm
      so nobody knows
    • Apr 13 2011 | 12:27 am
      a refined case with a pak and a pack strategy
    • Apr 13 2011 | 12:34 am
      This works too
      Out of curiosity - why are you patching it like this?
    • Apr 13 2011 | 12:52 am
      OK EJ tells me it's the pak object playing up in a recursive situation.
      You should work around it.
    • Apr 13 2011 | 9:24 am
      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
    • Apr 13 2011 | 2:12 pm
      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.
    • Apr 13 2011 | 2:12 pm
      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.
    • Apr 13 2011 | 3:40 pm
      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,
    • Apr 13 2011 | 6:15 pm
      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 ? :)
    • Apr 13 2011 | 6:19 pm
      This one is even more elegant
    • Apr 13 2011 | 7:26 pm
      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.