[PD] (no subject)

[Mathieu Bouchard]

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