few thoughts about the clumsy pattr object
Jun 17 2012 | 5:09 am
Hello,
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 amFor clarity (pattr object as an alias) you may use the @bindto attribute instead of wire connection.
- Jun 17 2012 | 11:33 amYou 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 amthanks
- Jun 18 2012 | 5:49 pmI 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:
