[PD] pddp - a proposal

[SYi at wavexpress.com]

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 at davesabine.com] 
Sent: Thursday, June 06, 2002 3:26 PM
To: pd-list at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020606/8e2e971b/attachment.htm>