[PD] pdmtl abstractions questions and comments (previously without a subject)
Hans-Christoph Steiner
hans at eds.org
Tue Jul 3 11:59:21 CEST 2007
I am glad to see the PdMtl stuff progressing. There is already lots
of objects for Pd, now the work of organizing all this stuff into
coherent libraries is definitely the next step.
Some comments inline below:
On Jul 1, 2007, at 1:14 AM, Thomas O Fredericks wrote:
> This a follow up to a few comments and questions sent by Mathieu
> Bouchard.
>
> In this text, Mathieu's comments and questions are preceded by a "M:".
> My answers are preceded by a "T:".
> Every subject is separated by a: ********
>
> Please feel free to contribute to this discussion.
>
> ********
>
> M: '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.'
>
> T: In the http://wiki.dataflow.ws/PdMtlAbstractions/Usage page of the
> wiki, the "Special characters in abstraction names" section specifies
> that:
> a) abstractions that finish with "_~" are graphical signal objects
> (the only exception to this rule, and this might change, are the
> abstractions in the gui folder. These abstractions are used to create
> other "_" abstractions or to help debugging).
>
> b) abstractions that finish with "_" are graphical abstractions.
> Sometimes, we create an abstraction without a gui, then we create a
> gui that wraps the same abstraction. The name of both abstractions
> will be the same, except that the second version will have a "_"
> appended.
This sounds to me that you are exposing the implementation in the
interface. The interface should be defined separately from the
implementation, and definitely does not need to reflect it. When
using an object, it is a distraction to think about the
implementation of that object. Instead the programmer should be
thinking about the implementation of the program that is being
built. Therefore, the programmer would only need to know about the
interface.
> ********
>
> M: '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'
>
> T: Although I prefer abstractions without a "-" or a "_" in their
> names, others do not. But, since our wiki states that "class names
> with multiple words in the name should use underscores to separate
> words (i.e [iem_anything_kernel], [curve_log], [define_loudspeakers],
> [my_canvas], etc.)", and this follows the
> http://puredata.info/docs/developer/CodeGuidelines, I will start the
> conversion of all names so it fits this standard. All abnormal
> abstractions will be renamed (thanks a lot for the work Mat :) ).
Sounds like a good idea.
> ********
>
> M: "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."
>
> T: This is probably an oversight, please give examples of the
> erroneous help files.
It is definitely useful to have separate *-help.pd and *-example.pd.
A help patch should be a complete reference for the interface of the
object with simple illustrations of how to use it. An example patch
should be first and foremost a complete working program with comments
documenting various important aspects of how the related object is
being used.
>
> ********
>
> M:- '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? '
>
> T: I agree. The tern "generate" does not limit itself only to audio,
> but encompasses a lot of control abstractions. The basic problem was
> that the list of abstractions in this category was getting way out of
> hand. We had to find a solution. We asked ourselfs if we only keept
> control or signal abstractions in the generate category? We decide to
> spread the control abstractions around the other categories. By the
> way, we definitely do not want to create a category that ends with a
> "~" because who wants to instantiate an abstraction with the name
> generate~/bell~ ?
>
> The "synth" folder groups abstractions that are more like "complete"
> "midi" instruments (or at least try to be). Think of the "generate"
> category as the building blocks for the "synth" category. If this
> still seems to confusing, please reply with an alternative.
>
> ********
>
> M: 'likewise, what's the difference between "fx" and "transform"? I
> don't get it.'
>
> T: The transformation category groups abstractions that transform
> stuff with no direct reference to any musical context. The "fx"
> category groups abstractions that modify signals in a musical context.
> You can't ask a musician to "repeat~" or "smooth~" his guitar sound.
> But you can ask him to "delay~", "echo~" or distort it. That's the
> basic difference between both categories. Is it really confusing? If
> you still find it confusing, where should we move the abstractions
> from the "transform" category?
>
> ********
>
> M: 'the "math" folder is especially useless. As a math graduate I
> feel that byour 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.'
>
> T: The problem is that in any programming environment 99% of what you
> are doing has to do with math. The basic principle behind the
> categories where to think of them more as verbs, actions or types,
> instead of categorizing stuff along the c standard (or whatever it
> could/should be called). The verb, action or type categorization
> method tries to follow the dataflow method. For example, swap, print,
> send, receive, select, route, pack, etc are all verbs. That is why I
> imagined that categories should also follow this scheme. "math" is
> more of a category for stuff that hasn't found it's proper place yet.
> What do you think? Should the "number" category be include in "math"?
> How about "scale","random" or "anal". Tags instead of categories would
> be much better.
I disagree that 99% of programming is math, I'd say more like 9%.
It's much more logic than math, but I digress... "math" is a very
broad term, perhaps a more specific one would work better.
>
> ********
> M: " _index.pd files don't actually contain a list of the patches
> in the
> folder, so why is it called an index?"
>
> T: You are obviously not using either of the official pdmtl
> abstractions help browsers ( hbrowser.pd or hpopup.pd) as they
> automatically exclude all files that they consider are not help files.
> One of the "in progress" ideas of the pdmtl abstractions is to exclude
> from the listing of help files everything that starts with a "_".
>
> So what is "_index.pd" for? There is a patch called
> "pdmtl_indexmaker.pd" in pdmtl's root folder. It scans all the help
> files, extracts information like the description of the abstraction,
> comments about it, etc, and then scans for the file "_index.pd" to get
> the description of the category. The end result gives you what you can
> find here: http://wiki.dataflow.ws/PdMtlAbstractions/Contents
> This system makes it VERY easy to list all the abstractions, their
> categories and descriptions. The whole process of getting the data and
> updating the web page takes less than a minute.
If this index file is not intended to be read by humans, perhaps this
file should be .index.html, then most file browsers would hide it.
>
> ********
>
> M: '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?'
> T: Hum, so you asking us why we did not include a "mapping" category
> and then comment that "mapping" useless or too general???!!!
>
> if you are looking for something similar to the "mapping" category,
> you can check pdmtl's "scale" category.
If you are interested in the concept of mapping in the musical
instrument context, here is a paper that illustrates the idea
(written by people in Montreal :):
http://citeseer.ist.psu.edu/546217.html
.hc
>
>
> --
> thomas ouellet fredericks, tof at danslchamp.org, montreal, canada
>
>> ---------- Forwarded message ----------
>> From: Mathieu Bouchard < matju at artengine.ca>
>> Date: 29 juin 2007 14:52
>> Subject: [PD] (no subject)
>> To: pd-list at iem.at, Alexandre Quessy < listes at sourcelibre.com>
>>
>>
>> On Fri, 29 Jun 2007, Alexandre Quessy wrote:
>>
>>
>> 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 at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> --
>> Alexandre Quessy
>> http://alexandre.quessy.net
>> http://www.puredata.info/Members/aalex
>> _______________________________________________
>> abs mailing list
>> abs at dataflow.ws
>> https://dataflow.ws/cgi-bin/mailman/listinfo/abs-dataflow.ws
>>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
------------------------------------------------------------------------
----
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
More information about the Pd-list
mailing list