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
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs