[PD] setable values

Frank Barknecht fbar at footils.org
Fri Jul 23 00:40:10 CEST 2004

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.

 Frank Barknecht                               _ ______footils.org__

More information about the Pd-list mailing list