Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
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.
You cheat: It *will* break msp-pd, which won't run patches done on cvs-pd if those use your "set value". And to me at least MSP Pd is the canonical definition of the Pd syntax.
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.
Changing builtin objects is *not* just adding a new "feature". You are trying to change the *rules* of the Pd *language*, which all Pd versions still share.
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...
Either way I'd like to keep all current versions at least be able to understand each other, to speak the same language. If you want to extend the language by defining new words, that's fine. That's what functions or typedefs in programming languages do, and that's what externals do in Pd.
But your change is like changing a standard header file, so to say. Why do you want to introduce an incompatibility without need? Write an external and everyone is happy. value is defined using 114 lines of code, so writing an extended "value" external would be done in some minutes, it just means adding one function of 3 or 4 lines code. If you keep the code similar to the "value" code then it would be easy to add this to MSP Pd as well later.
But please don't change the language just because you need a missing feature, which wasn't missed by anyone else as long as I can remember reading this list.
Ciao
Frank Barknecht _ ______footils.org__