On Fri, 29 Jun 2007, Alexandre Quessy wrote:

3. pdm : the pd package manager

I don't know you get to write sentences like "A package is a zip file containing XML file and its contents.". What does package management, as an abstract concept, has to do at all with XML ?

And even in practice, it doesn't seem to have much to do with XML either: for example, both the .rpm format and the .deb format predate the .xml format, and you can pretty much that neither of them will be updated to use the magic of XML internally. It has to do in part with the fact that XML isn't magic at all.

1. stdpd : The standard pd library

I don't understand what problem would stdpd solve that your pdmtl abstractions don't already solve or that pd-extended as a whole doesn't already solve.

You seem to be very mistaken about what is PERL's standard library vs what is PERL's package database. The example that you pointed to is exactly a huge package database akin to a full Debian OS but for PERL modules only.

"Standard library" is normally meant to be that library that is always installed with pd. So far it means [fiddle~] [bonk~] [expr~] and only a handful more than that. If all that one ever sees is pd-extended though, standard library could mean a lot more; but overall, if you want to say "remodel all of pd-extended in the style of pdmtl abstractions namespacing" then why do you say that instead of confusing that with what is normally meant by "standard library"?

2. pd-doc : the pd auto documentation tool

Help-files are already documentation. While I think it *might* be an interesting project, it very much depends on details that you haven't stated, and that makes all the difference. If it needs a lot of boilerplate from the help-writers and programmers, you may forget it already, and if it just dumps the comments of each page in random order in a web page, you may also forget it already. You might consider building an automatic screenshot system.

4. The pd objects wiki

I think that it's worth fighting so that classes really get called classes, because that's all they are. It's not like pd is one of those systems that blur the distinction between objects and classes through the actual programming constructs themselves. The only blur of distinction is in the documentation and the workshops and the speech and all it achieves at that level is confusion about how pd works. (e.g. $0 is easier to explain if people know what a class is vs an object)

I have no idea what you're talking about when you bitch about MediaWiki and praise MoinMoin. It doesn't seem to follow at all from any of the previous text. Either the link is obscure or a sentence is missing.

Also, if anyone is interested in contributing to the PdMtlAbstractions with some patches or general help, please tell us.

Here are some of my findings about pdmtl:

• several signal classes names end in "_~" instead of "~" for no apparent reason. It seems that some nonsignal classes also end in "_" for no apparent reason.

• some class names are "like-this", some are "like_this", and some are "likethis", for no apparent reason. While this happens in the much less controlled world of pd's externals repository, I would expect more from the pdmtl abstractions.

• I think it's pretty standard that every *-help.pd file has to contain an object of the class that it documents. Breaking this rule by cutting the documentation into that and *-example.pd files seems pointless. It seems even more pointless when the content of both files together is small enough that it would fit very well in one single patch on a small screen. If you're lacking space you can use subpatches, but really, so far, *-example.pd files seems like a superfluous concept.

• it's not obvious that "generate" is only for audio, and there might be lot of other classes outside of "generate" who might be understood like their purpose is to generate something. Especially confusing is the "synth" folder: why is anything of "generate" not in "synth" instead or vice-versa?

• likewise, what's the difference between "fx" and "transform"? I don't get it.

• the "math" folder is especially useless. As a math graduate I feel that your concept of "math" is something that I lost somewhere along my path, or maybe that I never had it. Anyhow, 99% of what I'd call math stuff is outside of the "math" folder, so, what's the point.

• _index.pd files don't actually contain a list of the patches in the folder, so why is it called an index?

• convert/lightwave2freq doesn't use the correct constant. 2.99792e+08 is the closest you can write in pd (the exact value is 299792458). Because of this, this abstraction doesn't do what it advertises. You may as well round pi to 3.14.

• I see that you don't have a folder named "mapping" yet, but it's written in http://puredata.info/dev/PdLibraries, so I have to ask, what is a mapping? It seems like most object classes have the purpose "to map inputs to outputs". While browsing around in pdmtl abstractions, it seems like the term would apply to most of the stuff. So, what is that for?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada