[PD] pddp - a proposal

[David Sabine]

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 --------------
A non-text attachment was scrubbed...
Name: float.pd
Type: application/octet-stream
Size: 3048 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020606/2e4c8ba0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: int.pd
Type: application/octet-stream
Size: 2384 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020606/2e4c8ba0/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symbol.pd
Type: application/octet-stream
Size: 2038 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020606/2e4c8ba0/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: send.pd
Type: application/octet-stream
Size: 7482 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020606/2e4c8ba0/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: receive.pd
Type: application/octet-stream
Size: 448 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020606/2e4c8ba0/attachment-0004.obj>