attrui store and recall settings ?

    Oct 20 2011 | 9:45 am
    Hello, preset does not account attrui?
    I do not know if it's me but I have trouble with the box number in attrui: when I release my mouse attrui often changes the value of the box number. I tested with several mouse and the same.
    The various tests that I made with Gen MSP and Jitter are crazy.
    The first reason to update my Max 5;)
    Thank you team cycling74 for all this work and all these new ideas. I look forward to more information and tutorials.

    • Oct 20 2011 | 1:33 pm
      attrui doesn't support preset nor pattr since its magic is to grab the values directly from the object it's connected to.
    • Oct 20 2011 | 3:27 pm
      thank you for the reply Emmanuel.
      I saw attrui as a quick and convenient to work, but the magic of attrui beyond me.
      for example: I use hop a shot of the small wheel or Attributes of the object to take the position function. I automatically attrui position, great! it's magic: D but I finally make my pak position if I want to record my position.
      I find really a shame that attrui can not be saved.
    • Dec 31 2011 | 9:12 am
      Even though I totally get the magic of attrui, I kind of agree with Laurent - it's incredibly convenient to have a standardized label/value object, and if its state was savable via pattr/preset, it could replace all kinds of comments, multiple number boxes, etc.
      I'm wondering if attrui might be able to get an attribute for a second mode/state:
      Mode 1: attrui grabs values from object, attribute name can be changed via popup menu (just the way it works now)
      Mode 2: attrui no longer grabs values from object, attribute name is fixed, values are savable via pattr/preset. When patch is loaded, if no preset has been set, values could be grabbed once on load from object (so that attrui & object stay coordinated).
      As it is now, attrui is incredibly useful as long as I set the attributes of all my objects in the objects themselves. But the minute I start using pattr to save states, I have to either add pattr-compatible objects that feed into each attrui, or take out the attruis altogether and replace them with pattr-compatible objects (plus comments/labels). Either way, there's a lot of redundant patching that could be eliminated.
    • Jan 31 2012 | 9:25 am
      Bumping this with the same sentiment, really - a switchable mode that makes the value parameter one-directional would be a really great way of building patches.
      As it stands it means that for many attribute things I am now either:
      1) Connecting number boxes to a thing that already has number boxes...! or 2) going back to the old [someattribute $1] method, even though a much slicker method is right in front of me :-/
    • Feb 07 2012 | 1:28 pm
      +1 for storing/recalling attrui!
    • Feb 09 2012 | 10:11 pm
      > but I finally make my pak position if I want to record my position
      I still hope for something like a ";max freeze all_attributes" message ....
    • Mar 07 2012 | 4:29 pm
      Bumping this thread.
      Attrui does not work with preset. "Magic"? I vote "no"...
      The truly magical and mystical experience would be to use attrui to replace a lot of ugly message boxes and pak objects. Not possible without presets.
    • Mar 09 2012 | 5:09 am
      attrui doesn't really have much of a "state" so there's nothing to save in a preset. It's just a window into a different object.
    • Jun 09 2012 | 11:03 am
      It's possible to bind pattr objects to attributes of another named object, like this:
    • Jun 09 2012 | 5:03 pm
    • Jun 11 2012 | 12:30 am
      +1 for preset/attrui compatibility. attrui is too nice an interface not to be used to its full potential.
    • Sep 28 2013 | 4:47 am
      Well... attrui may be the "magic grabber" but that doesn't mean that what is grabbed should remain inaccessible.
      attrui doesn’t really have much of a “state” so there’s nothing to save in a preset. It’s just a window into a different object.
      No.. it's not just window. If it's "grabbing" values then it's more like a see-through container. If it can grab, contain and display, surely it's feasible to output.
      How about having an outlet that magically sends the values to another object. That will at least allow for a 'workaround' for the preset/pattr issue. There are so many potential uses of such functionality it boggles the mind.
    • May 15 2014 | 2:07 pm
      Bumping into this again today. Did a method for tying attrui into a preset/pattrstorage emerge in the mean time? It would be such an obvious feature...
    • Jun 27 2014 | 4:46 pm
    • Nov 14 2014 | 12:31 pm
      in max 7 values of attrui still can not be saved when you save the patch ???
    • Dec 01 2014 | 3:36 pm
      +1 attrui values being saveable with preset :-)
    • Feb 12 2015 | 8:37 pm
      +1 attrui values being saveable with preset :-)
      I didn't find this solution. Could you explain more precisely, please?
    • Feb 12 2015 | 8:57 pm
      @Michel8 What do you mean?? you didn't this solution ?
      That is my request not a solution.
      Although there is a workaround but in a pain in the neck for time efficiency, but then again , so is having a ton of [pak blab f f f ] in Jitter.
      Anyways the workaround involves using pattrstorage , and it worth it if you want to use pattrstorage's fade $1. I do use this feature to create timelines for specific camera positions , works like a charm.
      here is an example
      Let me know if you need help
    • Feb 12 2015 | 10:14 pm
      all right, I thought the +1 was the missing magic spell. So, it is still the same effort. Too bad and amazing! Thank you for your example.
    • Feb 12 2015 | 10:26 pm
      here is an even more straight forward patch ;-)
    • Dec 15 2016 | 1:31 am
      That is the best! Will save many hours. Thank you very much
    • Jan 05 2019 | 11:48 pm
      Wondering if this topic has changed to a more convenient solution with Max 8? Especially with patches using a lot of Jitter objects the following workarounds are not optimal. a) Transform -> Changed Attributes to Arguments makes patchers become visually overloaded and hard to read. b) Using [pak] with number boxes and [preset] as stated in a post above "...there's a lot of redundant patching that could be eliminated". c) Using scripting names and pattr is finally as cumbersome as b)
    • Dec 17 2019 | 12:56 am
      +1 still!
    • Mar 12 2020 | 10:23 pm
      How about scripting? Here's an quick-and-dirty abstraction called autoadd_attributes that uses thispatcher to generate and bind pattr objects. The abstraction takes the scripting name of the object and a list of attributes as patcher arguments:
      [autoadd_attributes myobject attr1 att2 attr3 …]
      Example usage:
      And an example json file:
      Seems to work. I can drop an autoadd_attributes object into any patcher. The pattrs are created inside the abstraction using @bindto and thus exposed to the pattr system. You never see the cruft. Saves typing at least.