hi all,
to do that, i can either create each |value| by messages, or (what i would prefer) "set" the value...
I can see your motivation, but my usual caveat applies here as well: You would create two incompatible Pd version with doing that as an internal: MSP Pd and CVS-Pd. I don't think it's a good idea, in fact I'm convinced, doing this is a bad idea and would make all hell break loose. ;)
first of all: it will not break anything. the cvs-pd will have a feature, the msp pd won't have. a msp patch will run on the cvs.
and: i'm convinced that it's not useful to keep pd as it is, just to remain the compatibility between cvs and msp. what we need is some way to integrate useful or neccessary stuff (like this, like the fftw support, like guenter's tooltips, like the threaded soundfiler, like thomas's simd stuffa) to the main pd branch. if each version of pd will be compatible to lower versions, i don't see any problem at all ... it's better than finding a workaround...
what we will need, is some kind of organization of the development, including a feature request and a bugtracking system that is used by everyone, users, developers and miller ... maybe we could use the sourceforge system or maybe someone knows / can set up another system ...
since object creation by messages for let's say 100 values is probably not very fast and the patch looks really ugly now, i'd prefer to use a setable value ...
I'm not really into the depths of the Pd source, but couldn't this create similar problems as settable sends/receives create? Also you could work with abstractions and pass the $0 from the parent patch as a creation argument. I do this extensively in RRADical to create somehow-non-local-but-still-not-totally-global variables.
there are no problems like with send/receive: if you want to send a "set" message, you will have a problem, but a |value| is only a storage for floating point numbers, so the message "set" to the |value| won't be used for something else... also, setting a "receive" is probably useful. for a setable send, we would either have to use a second inlet or use a message ...
cheers... tim