Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I still find it hard to figure out whether it's a good idea or not to extend objects in non-Max-compatible ways. In the case of "value" it's doubly complicated, since the current Max version might be unnecessarily baroque (although I haven't looked at it yet to know.)
I now looked up "value" in the Max Reference PDF, and there value can keep all kinds of messages, also lists and symbols, not only floats. Interestingly enough, the example patch shows sending a "set something" message through a [value] object which is then used to "set" a message box to read "something" after a second value.
So a "set" as suggested by Tim would not only introduce a new extension compared to Max, it would also render a certain direction in the future development of "value" invalid.
(Further in the doc, "value" in Max indeed gets slightly baroque: It accepts a "send receivername" message, to send the stored value to any receive of the name "receivername", rendering value as being another kind of "send")
I also don't know whether having a settable name for value is correct, or whether it is a better design to have an entirely different object which can switch among value objects (the way tabread can switch between tables for instance.) That would be more trouble to use but more consistent with the rest of Pd...
I never looked at it that way, but it sounds like a good solution. Trouble can always be hidden inside abstractions (the famous "another level of indirection"). But still I don't really see the need to have value setable. For one there already is [pool], which is a setable, optionally global container for lots of data -- a [value] on steroids. And then: although I use pool all the time, I seldom feel the need to change ("set") the pool's name.
Ciao
Frank Barknecht _ ______footils.org__