I have to agree that an organised documentation project for Pd would be invaluable.

If someone is planning on organising such a thing, I'm raising my hand as someone willing to participate.

• martin

[>] what I have in mind is a reference manual -- comprehensive and [>] synchronized with Pd development. One would use tutorials for [>] learning, help patches for a quick reminder and for checking [>] things, but the ultimate knowledge base is the reference manual. [>] Max has it, msp has it, even osw has it -- but not Pd.

Obviously, the first phase in this project is already underway...i.e. a few people show interest in such a project!

What's the next step?

I too am a willing participant. Perhaps Mr. Puckette, or somebody else with intimate knowledge of PD and it's source code, could provide some direction and guidance through the process? What's the first (next) priority?

Regards, Dave Sabine

p.s.: I would suggest that the documentation should be HTML format (rather than pdf, ps, etc.) because:

1. everybody with a web browser can participate in development of such a

document. 2. everybody with a web browser can access the documentation. 3. the documentation can provide downloadable examples. 4. etc. etc.

----- Original Message ----- From: "Josh Steiner" joschi@eds.org To: "martin" martin.dupras@uwe.ac.uk Cc: pd-list@iem.kug.ac.at Sent: Wednesday, May 15, 2002 4:27 PM Subject: Re: [PD] pddp - a proposal

ditto on both the support and willing participant counts

On Wed, 15 May 2002, martin wrote:

...

I have to agree that an organised documentation project for Pd would be invaluable.

If someone is planning on organising such a thing, I'm raising my hand

as

...

someone willing to participate.

• martin

...

[>] what I have in mind is a reference manual -- comprehensive and [>] synchronized with Pd development. One would use tutorials for [>] learning, help patches for a quick reminder and for checking [>] things, but the ultimate knowledge base is the reference manual. [>] Max has it, msp has it, even osw has it -- but not Pd.

---

Josh .. Yoshi .. Joschi .. xiphoidprocess.com .. eds.org/~joschi

I "ported" the documentation to SGML a a while ago. If you're all interested, let me know and I'll dig it out again.

On Wed, 2002-05-15 at 19:35, martin wrote:

I am of the opinion that HTML output for pd documentation if highly desirable. However, I would stress that HTML is probably not the best format to actually author and maintain such documentation.

Which raises the point: does anyone have any experience, or good pointers to existing documentation projects (for other subjects), documentation maintainence, and documentation formats (such as DocBook and SGML)?

• martin

...

p.s.: I would suggest that the documentation should be HTML format (rather than pdf, ps, etc.) because:

1. everybody with a web browser can participate in development of such a

document. 2. everybody with a web browser can access the documentation. 3. the documentation can provide downloadable examples. 4. etc. etc.

Hi, I was wondering if anyone has succesfully compiled gem-0.87 under RH7.2 . When I run "make" I get lots of warnings about " extra tokens at end of #endif directive " . Any thoughts on what I have to do to get this to work? Thanks Jim

hi,

i will also participate. i can/want to help on the GEM documentation side

lg

erich

On Thu, 16 May 2002 09:31:54 +0200 bernhard loibner bernhard@allquiet.org wrote:

Hi there

I have done a lot of max/msp programming, now I start to get into PD which is great. So I was wondering whether something like a "PD guide for maxers" exists somewhere out there?

not really...

While on the case, I have a stupid beginners question: I run PD on OSX and was just wondering if the various libs and externals that exist for win and linux can be used under OSX (e.g. the iemlib). Is this just a matter of compiling them for this platform?

yup, it should be as simple as that.

thanks b.

./MiS

Hi

On Wed, 15 May 2002, David Sabine wrote:

What's the next step?

Start writing! Talk the people at puredata.org about hosting the HTML.

I don't know enough pd to help, but I'm hoping to reap some benefits from the documentation. So I'm all for this one, but mostly as a cheerleader ...

-- \js

Hello,

Thanks to Mr. Musil, I now know how the 'interrupt' property works for the bng object. I've revised the 'bang.pd' that I submitted to this list yesterday to include this newly learned info - see attached.

On a similar note: I didn't receive any feedback about my most recent proposal to improve/expand PD's documentation (included below). I'll assume for the time being that NO NEWS IS GOOD NEWS. If anybody is opposed to what I have done to "bang.pd" then please raise your concerns...

Regards, Dave Sabine

----- Original Message ----- From: "David Sabine" dave@davesabine.com To: pd-list@iem.kug.ac.at Sent: Friday, May 31, 2002 7:45 PM Subject: Re: [PD] pddp - a proposal

Hello all,

This thread seems to have died...I'd like to revive it because I

personally

think it's very important.

I have an idea that might simplify the goals outlined in previous messages in this thread. There has been discussion in the past about creating a web-based document; (myself and a couple of others suggested the

possibility

of HMTL or the like); however, I've recently arrived at the opinion that within PD itself is the best location to build a comprehensive documentation.

Instead of creating a new resource (in the form of a web site or PDF or whatever), I 'm making a motion that the existing resource be improved (in the form of in-depth help documentation accessible through PD itself).

For instance, the best place to explain the usage, specifications, default values, and possible arguments of - let's say - the "LINE" object is in "reference/line.pd"

My reasons are simple:

1. There are already a number of web sites devoted to PD (pure-data.org,

Mr

Puckette's own site, Mark Danks site, IEM, and the list goes on).

Starting

a new site may result in yet another good but 'incomplete' resource.

2. A web site or downloadable document is merely a few clicks away for

most

users...but improving/revising the existing help documentation within PD

is

literally one click away.

3. Mr. Puckette's documentation is extremely helpful - however sometimes

is

way over my head, and other times not complete enough - I'm of the opinion that before any NEW resource is built, the existing files in PD should be maximized!

See the attached file - in it I have proposed a format for the design and layout of PD's supporting help files. Note that I make reference to

objects

that are not native to PD and I draw little or no distinction between

'bang'

and 'bng' (I don't they should be treated differently despite the fact

that

'bng' is not native to PD - perhaps Mr. Puckette and others may disagree with this ideology.)

Also note that you should feel free (with Mr. Puckette's approval of this attached document) to replace the existing version of "bang.pd" and

provide

this document in future releases of PD - Miller, that's your call!

Any thoughts? Regards, Dave Sabine

Hello all,

I didn't receive any rejections from my recent submittal of a newly renovated "bang.pd" help document. SO, I've continued in that direction and I'd like to submit a few more.

See the attachements:

bang.pd : I've revised the previous document so that it fits nicely on 1024 x 768.

bng.pd : I've simply added a little link to [bang]

print.pd : I've revised it to inlude explanation of arguments (naming the print object) and a few words about printing lists of messages.

loadbang.pd : I've created a new document because there was previously no help documentation for loadbang - I hope ya'll like it.

Again, I'll include my earlier disclaimer. 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'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

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

Hello IOhannes and all,

I appreciate your comments IOhannes and I agree that the "related objects" section needs to be more clear as to which objects are native to PD and which are not. (I suppose I left out that information because it takes up a lot of space on screen and I wanted to confine the documents to 1024 x 768.) In hindsight, I should have put a sub-patch in for related objects! That is something I will do very soon.

I also agree with you that this list is not the ideal way to distribute these files. I received a comment from Steven (SYi@waveexpress.com) who asked if these are available on the web somewhere.

IOhannes, I have web space of my own that I'm willing to use and I've started a web page already for this purpose. I appreciate your willingness to store the files at WikiWikiWeb - I plan to submit my zip file to your WikiWeb as well as maintain my own site.

Having said all of that, I've received enough encouragement that I've decided to continue my work as I find time. (Although I haven't received any approval or concerns from Mr. Puckette -- I just hope that he/you will tell me if and when I'm doing something terribly wrong or working against his/your goals for PD's development) In other words, if you like what I'm doing I'd really like to get an "Okay" from you - if you don't like what I'm doing I'd like to get a "Stop" message.

I have a question: perhaps I should send announcements of updates to PD-Announce? Or is this PD-List the appropriate place for such things?

Regards, Dave Sabine

p.s.: I've uploaded the latest files (with descriptions) to http://www.davesabine.com/media/puredata.asp?action=downloads That site now includes 10 revised help documents - my latest work is the "select.pd" file. p.s.s.: Very shortly I'll be visiting the WikiWikiWeb and submitting a small zip file there as IOhannes has recommended.

----- Original Message ----- From: "IOhannes zmoelnig" zmoelnig@iem.at

great, that you are doing the work.

still i have some proposals: 1.) as i have only looked into one help patch yet (namely "bang.pd") i do not know whether this applies to all patches: the "related objects" section is great, but maybe you should include a hint from which libraries (Gem, iemlib,...) they originate (where it is appropriate), since it gives error messages if the correct library wasn't loaded, and people get frustrated.

2.) i do not know how others think about this, but maybe it would be better to not propagate patches continously via this list. i'd prefer to have a (central) download-site where you (anyone) can upload your (his/her) contributions, and people can get it on demand. if you don't have access to your own webspace, feel free to use ftp://iem.kug.ac.at/incoming/pdwiki/pddp (maybe with announcments at the wiki-page http://pd.iem.at/pdwiki in addition to the list)

mfg.c.asdr IOhannes

hi,

if both the time-interval, and the sample rate, are fixed and known, then use [env~ <npoints> <period>], which sends an rms value measured for an <npoints>-window, and converted to db, every <period> number of samples.

Otherwise, you might use an [env~] with a shorter window and the arithmetic mean driven by a [metro] (counting and accumulating each [env]'s output value, dividing and resetting for every [metro] bang).

Krzysztof

David Jonsson (II) wrote:

I want to get the mean value of the intensity of a signal for a specific time-interval, typically 100 ms.