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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
