Hello,
Are these files available on the internet somewhere? If anything, maybe you could zip all the ones you do so that if someone wanted to, they could just unzip over the current documentation. Sort of a documentation pack.
Thanks, steven
-----Original Message----- From: David Sabine [mailto:dave@davesabine.com] Sent: Thursday, June 06, 2002 3:26 PM To: pd-list@iem.kug.ac.at Subject: Re: [PD] pddp - a proposal
Hello all,
I've continued in my original direction and received an encouring message from Mr. Watson which inspired me to submit THIS message with the following attached documents:
float.pd - I've revised this document to include a explanation of floating point numbers.
int.pd - after revising the 'float.pd' document, I decided that the 'int.pd' was the next logical step. Also, i've begun to view this object as merely a tool to truncate a fraction - I see no other use for it seeing as PD keeps all numbers as 32-bit floating point. Perhaps this object is also useful if developing patches for PD and MAX/MSP simoultaneously. HOWEVER, I think that the authors of PD and its externals might want to consider eliminating this object in future versions - is "deprecate" the appropriate term? If 'truncation' is the only unique feature of this object, then perhaps there should be a [truncate] object or an object which will round-off a floating point number and drop the remainder. Then again, if it's important to retain association with MAX/MSP, then this object might be more valuable than I think...
symbol.pd - I've created this new document. I felt it would be helpful to see examples of how 'symbols' are stored and retreived from the object. I'm starting to feel that further explanation of data types and methods will be helpful. For example, I initially thought that the symbol object would store a symbol by sending it a "set foo" type of message. But of course that doesn't work...the message needs to be "symbol foo". THEN I REALIZED that "set" is a 'method', but the [symbol] object wants to know the 'data type' and has no method for 'set'. HENCE, to store a symbol, you must use "symbol foo" or "symbol dog" to announce to the object that what you are about to send it is in fact a 'symbol'. (Keep in mind that i'm speaking here of the RIGHT inlet.)
send.pd - I've revised this document to explain why it might be necessary to create local variables (as opposed to global), and how some 'special' objects contain their own send and receive functionality.
receive.pd - again, this seemed like the next logical step after I worked on "send.pd".
You should feel free (with Mr. Puckette's approval of these attached documents) to replace the existing versions of these files and provide this document in future releases of PD - Miller, that's your call!
Also note: I'm rather enjoying this and I'm learning little things here and/or there. I'll stop if somebody tells me to...I'll change directions if somebody suggests a new path...I'll take requests if you're enjoying this work...otherwise I'll forge ahead as I see fit.
Regards, Dave Sabine