moving this thread to the pd-dev list...

...

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.

the problem with a set message is, we wouldn't be able to store the symbol "set" or a list beginning with set. what we _could_ do, is adding a second inlet, that listens to a "set" message to set the value name and that's accepting the "get x" message, that returning the atom nr. x of a list...

it would probably be able to add this as external. but probably this value wouldn't be compatible with the internal values (t_vcommon), since they are only based on a t_float.

we could extend the internal value object to contain atom lists, and add an (in/external) extended value object (with "set" with "get x")

cheers ... tim