few thoughts about the clumsy pattr object

    Jun 17 2012 | 5:09 am
    I am learning about preset management objects in MAX and I am maybe missing something, but are the wires going from [pattr] object really bidirectional? I thought that we have data flowing from outlets to inlets and I find the way the [pattr] object works really confusing + it also makes it quite useless in some cases. For example, when building some GUI my own way (not using the basic GUI objects, but LCD object + some logic around it, it's sometimes a different place (inlet) where I want to recall value and different place (outlet) from where i want the values to be stored.
    Seems to me, that having [pattr-in ] and [pattr-out ] objects separately would be much more reasonable. More useful + it would be much more intuitive to have data flow only from outlets into inlets. I can see, that replacing the [pattr] object would not be possible at this point, but maybe just adding a separate objects for storing and recalling would still make sense?
    what do you think?

    • Jun 17 2012 | 9:57 am
      For clarity (pattr object as an alias) you may use the @bindto attribute instead of wire connection.
    • Jun 17 2012 | 11:33 am
      You can also use pattr's inlet and first outlet to set and get the value. But beware of feedback loops, because pattr will immediately output the value it receives.
    • Jun 18 2012 | 2:12 am
    • Jun 18 2012 | 5:49 pm
      I would use bindto or better yet, use [autopattr] if you only need to store it in the GUI object. Then you can simply set by scripting name from [pattrforward].
      Interestingly, [pattr] has a check against stack overflow, which was interesting to learn: