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.
********
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 :) ).
********
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.
********
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.
********
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.
********
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.
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@danslchamp.org, montreal, canada
---------- Forwarded message ---------- From: Mathieu Bouchard < matju@artengine.ca> Date: 29 juin 2007 14:52 Subject: [PD] (no subject) To: pd-list@iem.at, Alexandre Quessy < listes@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@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@dataflow.ws https://dataflow.ws/cgi-bin/mailman/listinfo/abs-dataflow.ws
PD-list@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
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.
I do not understand your comment, but here are more details on how this works: a pdmtl abstraction whose name ends with a "_" (or a "_~") is usually exactly the same abstraction as one that has the same name but does not end with a "_" (or "_~"). For the programmer, there is no difference between the inlets or outlets of both versions. The only difference is that in one version, the abstraction is a Graph On Parent that displays on screen controls, while the other does not. Usually when I am programming, I will use the nice and convenient "_" (GOP) version. But, since we all know Pd's graphic engine is real slow, when it is time to set up an installation or do a performance or when I generate the abstractions dynamically , I will switch the abstractions to the non GOP version WITHOUT hurting in any way the interconnection between all the objects. Also, since the "_" abstractions simply wrap their counterparts, they are both automatically updated if the "engine" is updated.
Tom
-
Hans-Christoph Steiner -
Thomas O Fredericks