On Sun, 1 Jul 2007, Thomas O Fredericks wrote:
Ok, thanks for the link, I don't know why I didn't see that.
a) abstractions that finish with "_~" are graphical signal objects
Ok, but I don't think that the "_" character is so distinctive. I mean, it's enough to distinguish unambiguously, but it's still looks pretty close to a space, and it doesn't seem to have the kind of appeal to it that ~ has by looking like a wave or # has by looking like a grid (GridFlow was using @ before, and the mnemonic was less obvious). Perhaps that the ascii code offers too few characters and using unicode is too weird; then I'll concede that if you believe that there has to be a single-char suffix, underscore is not a bad choice at all.
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
Ok. Perhaps the problem is that some people's conception of words is different. Witness:
http://upload.wikimedia.org/wikipedia/en/5/5b/New_Zealand_0577.jpg
http://en.wikipedia.org/wiki/Lopado...pterygon
http://upload.wikimedia.org/wikipedia/commons/e/e8/Llanfairpwllgwyngyllgoger...
http://www.websterlakeassociation.com/images/Cropped%20Thompson%20Road%20sig...
this follows the http://puredata.info/docs/developer/CodeGuidelines
Ok, I don't particularly remember reading them back when they were posted. Now that I read them I'd like to say that the part about namespaces is quite bad: if I make a more descriptive name for a class that is really a lot like [poil], it would be something that ends in "_poil". However this means that a prefix is added to the name. The same section says that prefixes are to be turned into geiger namespaces, that is, folders. Let's say that the folder is named "patate". But then I cannot use the original [poil] anymore in that folder because pd picks up the locally defined [patate/poil] as being poil itself, hiding the prefixless [poil] that I need. Therefore a prefix is required. Then I might call it patate/patate_poil.pd, but that's redundant, so I remove the folder so that it's just called [patate_poil], and then we're back to prefixes. However if pd wasn't doing that and if there wasn't [import] then the slash wouldn't be anything more than a tilted underscore. So what are those guidelines good for?
All abnormal abstractions will be renamed (thanks a lot for the work Mat :)
(What are you talking about?)
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. T: This is probably an oversight, please give examples of the erroneous help files.
Actually there's only one *-example.pd file that I can see in 2007-05-29, it's init/at_parse-example.pd. (I haven't done an svn checkout and for the previous mail I was using the web interface of svn.)
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.
You mean alternative names or a solution along the lines of splitting the concepts? I don't even understand the concepts. I'd be glad to use some of the stuff in "generate" as "complete" instruments, if I was still composing any music, but else I know composers who'd do exactly that.
If you still find it confusing, where should we move the abstractions from the "transform" category?
Why not put stuff outside of categories? (Does everything have to be in a category?)
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).
uh, what's that "C standard" that you are talking about? I don't think that C standards says anything about the use or non-use of verbs in function names. If you're thinking about something else then you'd have to tell me whose convention it is so that I can find what its rules are so that I can see how it contrasts with your way. Perhaps a Kernighan&Pike book has something to say about that, but I never read those, just flipped some pages a bit.
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.
bang, float, symbol, int, spigot, moses, value, metro, line, timer, cputime, realtime, pow, mtof, random, ... there are lots of nouns as classnames in pd too. Where it's ambiguous, I count a word as a noun if the verb wouldn't be a good description of what happens. e.g. "to line" isn't like [line], so i counted line as being noun; but [delay] makes equal sense as "to delay" or "a delay", so I'd count it as being either both or neither.
There's no agreement on the use of noun vs verbs at the level of pd/max and even less at the level of all dataflow things. So you can't really say that there's a "dataflow" way of naming things.
In regular (non-dataflow) object-oriented programming, there is that concept that classes are nouns, vs that methods are verbs, but some people take it too seriously, to the point that it gets cumbersome: you wouldn't send a message "duration $1" because it's a noun, it would have to be called "set_duration $1". That's the Java style. The Ruby style is that just because methods have verb-like properties doesn't mean that they have to map to English verbs, so it would be called "duration= $1", where = is the suffix meaning "to set" on a noun, whereas no suffix would mean "to get". (in pd, emphasis is on setting, so "to set" is the expected meaning of a lone noun for a method name).
"math" is more of a category for stuff that hasn't found it's proper place yet. What do you think?
I think that category names have to be figured out pretty quick if people are expected to start using the names in backwards-compatible ways. Else you get into what is called "bit rot" - a program is not just the contents of source files, it's also a set of relationships with its environment, and especially, its direct dependencies.
Should the "number" category be include in "math"? How about "scale","random" or "anal".
I don't know. We could have a head-scratching party in my apartment, if you'd like some brainstorm about it. I didn't speak much when you made that presentation of pdmtl abstractions because that was my first exposure to it so I had to think about it a bit.
Tags instead of categories would be much better.
If you mean that there wouldn't be namespaces and instead there would be a non-arborescent taxonomy whose purpose would still be to organise similar objects together documentation-wise, then I would say that I agree.
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.
I'm using /usr/bin/ls or the svn web interface. What's wrong with either? I'm obviously not asking this as a simple user.
So what is "_index.pd" for?
Uh, my question actually is "why is _index.pd called an index?".
T: Hum, so you asking us why we did not include a "mapping" category and then comment that "mapping" useless or too general???!!!
Yes... if you don't understand the logic of it, then I don't know what I can do... I'd rather raise the issue before the category is even created. I didn't pick "mapping" as a random victim either: it's specifically because Alex had previously asked me questions about making abstractions in the style of HCS's "mapping" library, and that got me quite puzzled, like, why one would actually want such a library in the first place, etc.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
this follows the http://puredata.info/docs/developer/CodeGuidelines
Ok, I don't particularly remember reading them back when they were posted. Now that I read them I'd like to say that the part about namespaces is quite bad: if I make a more descriptive name for a class that is really a lot like [poil], it would be something that ends in "_poil". However this means that a prefix is added to the name. The same section says that prefixes are to be turned into geiger namespaces, that is, folders. Let's say that the folder is named "patate". But then I cannot use the original [poil] anymore in that folder because pd picks up the locally defined [patate/poil] as being poil itself, hiding the prefixless [poil] that I need. Therefore a prefix is required. Then I might call it patate/patate_poil.pd, but that's redundant, so I remove the folder so that it's just called [patate_poil], and then we're back to prefixes. However if pd wasn't doing that and if there wasn't [import] then the slash wouldn't be anything more than a tilted underscore. So what are those guidelines good for?
Actually that is why I didn't yet use directory prefixes for my abstraction libraries, especially the [list]-abs. Without their prefix -- [list]-abs is using a dash instead of an underscore or a slash, because underscores are harder to type on german keyboards and because not following guidelines leads to more fun in life --, objects like [list-abs] or [list-moses] are impossible to use in Pd anyways, as [abs] and [moses] are builtins.
So a prefix directly in the object name is necessary. "list-" to me looked like the most natural choice - and it doesn't need "Shift" on german keyboards to type, so I was set.
The choice of pdmtl was "list/". Another good and obvious choice, but to me it doesn't really have any advantages over "-" (and needs "Shift" on german keyboards...) Unless you stick to unused names only, you always need to keep the prefix in the object name.
If someone else does an abstraction collection for lists, I'd say, "list_" or "list." are two other good choices.
Where directory prefixes shine however is for making packages of externals and abstractions. Pd-extended is the prime example: It can ship all five [counter] objects, which would be impossible without subdirectories for each collection. Whether shipping five counters is desirable is debatable, but at least people have a choice.
However shipping objects (or classes, as you suggest to call them) in subdirectories creates a possibly uncomfortable side effect: It introduces an additional, possible prefix: the directory name. So people start to use objects called [list-abs/list-abs] just because for packaging reasons, list-abs.pd in pd-extended lives in a directory called "list-abs". Now that's what I call redundancy: Instead of one, we get two prefixes. At least my help-files still work.
pdmtl may face a similar or worse problem when people start using objects with names like [pdmtl/list/op]. Here not only help-files will be broken, as the help file "list/op-help.pd" uses an object called [list/op] which is unavailable unless "pdmtl" is in the path. Actually all objects using [list/x]-objects are broken then!
To somehow be prepared for that pdmtl would need to use [import] or [declare -path ..] in every abstraction, and take note, that [declare -path ..] will also activate all other subdirectories of ptmtl for that patch - mostly this won't be a problem.
All this to me seems to kind of pervert what Guenther Geiger actually intended when suggesting directory prefixes and initiating the CVS-repository. Instead of shipping five [counter]s, one [counter] would be shipped as the default [counter] directly in extra, other counters would be hidden in subdirectories for special use, but be deprecated. The reality now is, that [flatspace] announces that it is deprecated, and the "Path" window is filled with more entries than it can handle.
I think that category names have to be figured out pretty quick if people are expected to start using the names in backwards-compatible ways. Else you get into what is called "bit rot" - a program is not just the contents of source files, it's also a set of relationships with its environment, and especially, its direct dependencies.
[list-abs/list-abs] is bit-rot.
Tags instead of categories would be much better.
If you mean that there wouldn't be namespaces and instead there would be a non-arborescent taxonomy whose purpose would still be to organise similar objects together documentation-wise, then I would say that I agree.
I had to look up arborescent, after that I agreed, too.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
[...] Without their prefix -- [list]-abs is using a dash instead of an underscore or a slash, because underscores are harder to type on german keyboards and because not following guidelines leads to more fun in life [...]
Wow, talk about cheap thrills :) Doesn't the German keyboard have a "/" key over the number 8 on the numpad (that is if you are not using a laptop)?
Unless you stick to unused names only, you always need to keep the prefix in the object name.
The pdmtl abstractions REQUIRE that you keep the folder prefix. The prefix IS part of the abstraction's name. But this is not a problem because it takes as long to type list/whatever than list-whatever.
[...] objects like [list-abs] or [list-moses] are impossible to use in Pd anyways, as [abs] and [moses] are builtins.
I created a version of list/abs in our svn repository. It works just fine. I do not understand what is impossible?
[..] So people start to use objects called [list-abs/list-abs] just because for packaging reasons, list-abs.pd in pd-extended lives in a directory called "list-abs". Now that's what I call redundancy: Instead of one, we get two prefixes. At least my help-files still work.
This is definitely ridiculous. Tthe pdmtl abstractions installation instructions require one line of text to be added to the path and another as a startup flag. We are currently working on adding these by default to pd-extended.
pdmtl may face a similar or worse problem when people start using objects with names like [pdmtl/list/op]. Here not only help-files will be broken, as the help file "list/op-help.pd" uses an object called [list/op] which is unavailable unless "pdmtl" is in the path. Actually all objects using [list/x]-objects are broken then!
Once both lines are added to pd's configuration everything works great. Even the help files. However, creating an abstraction with [pdmtl/list/op] is not recommended. The same goes for creating a [cyclone/counter]. Instancing in this fashion in simply too long (while you simply had to add cyclone to your path) and breaks compatibility with other people's distributions (for example people that use the cylone.pd_linux instead of the expanded folder or whatever it is called).
Tom
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
[...] Without their prefix -- [list]-abs is using a dash instead of an underscore or a slash, because underscores are harder to type on german keyboards and because not following guidelines leads to more fun in life [...]
Wow, talk about cheap thrills :) Doesn't the German keyboard have a "/" key over the number 8 on the numpad (that is if you are not using a laptop)?
I never use the numpad, not even for numbers, it's too far away.
Unless you stick to unused names only, you always need to keep the prefix in the object name.
The pdmtl abstractions REQUIRE that you keep the folder prefix. The prefix IS part of the abstraction's name. But this is not a problem because it takes as long to type list/whatever than list-whatever.
[...] objects like [list-abs] or [list-moses] are impossible to use in Pd anyways, as [abs] and [moses] are builtins.
I created a version of list/abs in our svn repository. It works just fine. I do not understand what is impossible?
I meant, it's impossible to use them *without* their prefix: Even with something like [import list] you couldn't use [abs] when you want to get [list/abs], because [abs] is builtin.
pdmtl may face a similar or worse problem when people start using objects with names like [pdmtl/list/op]. Here not only help-files will be broken, as the help file "list/op-help.pd" uses an object called [list/op] which is unavailable unless "pdmtl" is in the path. Actually all objects using [list/x]-objects are broken then!
Once both lines are added to pd's configuration everything works great. Even the help files. However, creating an abstraction with [pdmtl/list/op] is not recommended.
Same for [list]-abs: I wouldn't recommend to use [list-abs/list-abs], though it works.
The same goes for creating a [cyclone/counter]. Instancing in this fashion in simply too long (while you simply had to add cyclone to your path) and breaks compatibility with other people's distributions (for example people that use the cylone.pd_linux instead of the expanded folder or whatever it is called).
Note that you're saying here that [counter] should be called without "namespace", while [list/abs] should be called with "namespace". Maybe talking about "namespaces" is just confusing and talking about plain "names" for objects or classes would be clearer. Names must not conflict, but building your non-conflicting names can be done in several ways. Many involve using some kind of repeating prefix. Whether that prefix is separated with a slash or a dash doesn't matter that much.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Names must not conflict, but building your non-conflicting names can be done in several ways. Many involve using some kind of repeating prefix. Whether that prefix is separated with a slash or a dash doesn't matter that much.
Little addition: me chosing "-" and pdmtl choosing "/" as seperator has the advantage that people can use both (list-)collections at the same time, which is useful as they follow a slightly different philosophy: [list]-abs is meant to implement common list-operations as dependency-free as possible, so using externals is forbidden, while pdmtl uses loads of externals.
Btw.: There is a yet unpublished version of many [list]-abs which *do* use externals to speed things up. By putting these in front of or using them instead of the external-free [list]-abs in your path, one can profit from the speed-up and still use the external-free interface to write patches, that also run on everyone's plain Pd. In a similar way, features only available in newer Pds - like [list length] - can be used without requiring that people upgrade to the latest Pd.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Mathieu Bouchard a écrit :
The same section says that prefixes are to be turned into geiger namespaces, that is, folders. Let's say that the folder is named "patate". But then I cannot use the original [poil] anymore in that folder because pd picks up the locally defined [patate/poil] as being poil itself, hiding the prefixless [poil] that I need. Therefore a prefix is required. Then I might call it patate/patate_poil.pd, but that's redundant, so I remove the folder so that it's just called [patate_poil], and then we're back to prefixes. However if pd wasn't doing that and if there wasn't [import] then the slash wouldn't be anything more than a tilted underscore. So what are those guidelines good for?
Thanks to make 'what namespace is' clear.
If you mean that there wouldn't be namespaces and instead there would be a non-arborescent taxonomy whose purpose would still be to organise similar objects together documentation-wise, then I would say that I agree.
I vote for no namespace, no prefix, it's difficult enough to organize files for pd, and many prefixes won't work with externals that requires a script, for example if I put my python scripts into extra/python, I'd call the script with [pyext] with a namespace like that [py python/myscript myclass] but obviously it won't work, in fact I'd have to start pd with -path python or put the script into the patch's folder and put no namespace for the script file reconized, same thing with tcl scripts, etc... I'd add that a good taxonomy should take into account any pd and external related files.
I vote for no namespace, no prefix, it's difficult enough to organize files for pd, and many prefixes won't work with externals that requires a script, for example if I put my python scripts into extra/python, I'd call the script with [pyext] with a namespace like that [py python/myscript myclass] but obviously it won't work, in fact I'd have to start pd with -path python or put the script into the patch's folder and put no namespace for the script file reconized, same thing with tcl scripts, etc... I'd add that a good taxonomy should take into account any pd and external related files.
Using no namespace, no preffix is what started this whole mess.
Tom
On Mon, 2 Jul 2007, Patco wrote:
Mathieu Bouchard a écrit :
The same section says that prefixes are to be turned into geiger namespaces, that is, folders. Let's say that the folder is named "patate". But then I cannot use the original [poil] anymore in that folder because pd picks up the locally defined [patate/poil] as being poil itself, hiding the prefixless [poil] that I need. Therefore a prefix is required. Then I might call it patate/patate_poil.pd, but that's redundant, so I remove the folder so that it's just called [patate_poil], and then we're back to prefixes. However if pd wasn't doing that and if there wasn't [import] then the slash wouldn't be anything more than a tilted underscore. So what are those guidelines good for?
Thanks to make 'what namespace is' clear.
Actually it doesn't work like that. I made a mistake in the example. There are several namespace problems that are similar to the above, but none that is exactly that. It's the class that is loaded first that has precedence. When you have a locally defined object class, you can't use it with its local name without a prefix, because else the builtin class gets priority, or else any class that registered itself as having just that name will. This goes pretty much against the concept of namespaces of every language except Perl (in which class names have to be fully-qualified; other global things don't have to)
I vote for no namespace, no prefix,
You can't argue the case for no prefix at all ever. There are lots of reasons to use prefixes at least sometimes. What's debatable is when they should be used and why. (in this context, whenever namespaces act just like prefixes, they're effectively the same, so they are debatable in the same way as prefixes are)
for example if I put my python scripts into extra/python, I'd call the script with [pyext] with a namespace like that [py python/myscript myclass] but obviously it won't work,
Here we are talking about class names at pd level. By putting the python class name as a 2nd or 4th element in the objectbox, Pyext bypasses Pd's own class naming mechanisms and also rejects the principle that no matter which language you use to extend pd, you can do essentially the same. Several other things break that principle: e.g. abstractions can't use variable number of arguments in their $-args. Pyext's class naming is another of them.
I believe that most other language interfaces allow direct registration of pd classes, but I haven't tried them and don't really recall. At least I can tell you that anything that is not an abstraction in GridFlow currently goes through Rubyext. (pd class registration ability in Ruby will not change, but which classes go through Rubyext will.)
I have never considered otherwise than direct class registration for any external language, and I'm kind of puzzled about why would anyone ever do otherwise. Anyway: I could show you a bit of C that creates an alias that redirect a certain name to [py python/myscript myclass]. Else there is supposedly the new sys_register_loader (pd 0.40) which can help with that; it would not have been required but Thomas decided to share Hans' exaggeration of the power of sys_register_loader.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hi,
Nice conversation. :)
2007/7/3, Mathieu Bouchard matju@artengine.ca:
Here we are talking about class names at pd level. By putting the python class name as a 2nd or 4th element in the objectbox, Pyext bypasses Pd's own class naming mechanisms and also rejects the principle that no matter which language you use to extend pd, you can do essentially the same. Several other things break that principle: e.g. abstractions can't use variable number of arguments in their $-args. Pyext's class naming is another of them.
Abstractions can't use variable number of arguments in their $-args ... unless one uses dollarg from iemlib ! (T. Musil)
Alexandre Quessy wrote:
Hi,
Nice conversation. :)
2007/7/3, Mathieu Bouchard matju@artengine.ca:
Here we are talking about class names at pd level. By putting the python class name as a 2nd or 4th element in the objectbox, Pyext bypasses Pd's own class naming mechanisms and also rejects the principle that no matter which language you use to extend pd, you can do essentially the same. Several other things break that principle: e.g. abstractions can't use variable number of arguments in their $-args. Pyext's class naming is another of them.
Abstractions can't use variable number of arguments in their $-args ... unless one uses dollarg from iemlib ! (T. Musil)
or unless you apply my $arg patch to pd (can be found in the patch-tracker); i thought pd-extended uses that one.
mfg.asdr IOhannes
On Tue, 3 Jul 2007, Alexandre Quessy wrote:
2007/7/3, Mathieu Bouchard matju@artengine.ca:
Here we are talking about class names at pd level. By putting the python class name as a 2nd or 4th element in the objectbox, Pyext bypasses Pd's own class naming mechanisms and also rejects the principle that no matter which language you use to extend pd, you can do essentially the same. Several other things break that principle: e.g. abstractions can't use variable number of arguments in their $-args. Pyext's class naming is another of them.
Abstractions can't use variable number of arguments in their $-args ... unless one uses dollarg from iemlib ! (T. Musil)
or [args] from gridflow, which handles non-zero defaults.
or Johannes Zmölnig's modification of pd to accept $* as meaning "all arguments" http://sourceforge.net/tracker/index.php?func=detail&aid=1543850&gro...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Am 03.07.2007 um 16:55 schrieb Mathieu Bouchard:
I have never considered otherwise than direct class registration
for any external language, and I'm kind of puzzled about why would
anyone ever do otherwise. Anyway: I could show you a bit of C that
creates an alias that redirect a certain name to [py python/ myscript myclass]. Else there is supposedly the new
sys_register_loader (pd 0.40) which can help with that; it would
not have been required but Thomas decided to share Hans'
exaggeration of the power of sys_register_loader.
He's back!
greetings, Thomas
Mathieu Bouchard a écrit :
On Mon, 2 Jul 2007, Patco wrote:
I vote for no namespace, no prefix,
You can't argue the case for no prefix at all ever. There are lots of reasons to use prefixes at least sometimes. What's debatable is when they should be used and why. (in this context, whenever namespaces act just like prefixes, they're effectively the same, so they are debatable in the same way as prefixes are)
Indeed I can't argue for no prefix at all, because I am using prefixes in my sets of abstractions, particulary for sorting them in a dynamic patching process, and that makes patches difficult to use fully outside of their context unfortunately.
MB > Ok, but I don't think that the "_" character is so distinctive. I mean,
it's enough to distinguish unambiguously, but it's still looks pretty close to a space, and it doesn't seem to have the kind of appeal to it[...]
We used "!" (an upside down "i" that stands for interface) before instead of "_" but we had to continuously escape it in command lines and scripts. So we settled on "_" instead. Of course, we would have liked to use "#", but Gridflow's use of it is much better :)
MB > Ok, I don't particularly remember reading them back when they were posted.
Now that I read them I'd like to say that the part about namespaces is quite bad: if I make a more descriptive name for a class that is really a lot like [poil], it would be something that ends in "_poil". However this means that a prefix is added to the name. The same section says that prefixes are to be turned into geiger namespaces, that is, folders. Let's say that the folder is named "patate". But then I cannot use the original [poil] anymore in that folder because pd picks up the locally defined [patate/poil] as being poil itself, hiding the prefixless [poil] that I need. Therefore a prefix is required. Then I might call it patate/patate_poil.pd, but that's redundant, so I remove the folder so that it's just called [patate_poil], and then we're back to prefixes. However if pd wasn't doing that and if there wasn't [import] then the slash wouldn't be anything more than a tilted underscore. So what are those guidelines good for?
I have been using the pmdtl folder namespaces for a year now and have NEVER had a similar problem. I tried replicating the example in a practical context, but I cannot. This issue is a theoretical problem that never happens in a practical context. Also, this issue can only happen if you have abstractions that are not inside category folders (and this goes against the pdmtl folder architecture: all pdmtl abstractions require to be categorized). If you absolutely want to do this for absolutely no functionnal reason, simply prepend a "../" to the [poil] inside the [patate/poil].
You can even create an abstraction called [patate/counter] and instantiate a [counter] object in there and it will work correctly.
All abnormal abstractions will be renamed (thanks a lot for the work Mat :)
If you take a look at the pdmtl abstractions contents page ( http://wiki.dataflow.ws/PdMtlAbstractions/Contents ), you will see that all the abstraction names that contain two words are now separated by a "_".
MB > > 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.
All right then, I will probably move most of the stuff from [generate] to the [synth] category. The distinction is not clear enough.
MB > Why not put stuff outside of categories? (Does everything have to be in a
category?)
Yes, everything does have to be in a category. This constraint makes for an environment that is especially useful for newbies and resolves a lot of conflicts.
MB > I think that category names have to be figured out pretty quick if people
are expected to start using the names in backwards-compatible ways. Else you get into what is called "bit rot" - a program is not just the contents of source files, it's also a set of relationships with its environment, and especially, its direct dependencies.
I agree. I think we are almost there. We simply have to solve a few glitches.
MB > I don't know. We could have a head-scratching party in my apartment, if
you'd like some brainstorm about it. I didn't speak much when you made that presentation of pdmtl abstractions because that was my first exposure to it so I had to think about it a bit.
I would really appreciate that :)
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.
MB > I'm using /usr/bin/ls or the svn web interface. What's wrong with either?
I'm obviously not asking this as a simple user.
For newbies, the folder categorizing system really comes to life when using pdmtl's built in help browsers. See http://wiki.dataflow.ws/PdMtlAbstractions/Usage/Browsing I teach a lot of Max/Msp and the "new object" box is a godsend for them ( http://www.makingthings.com/teleo/products/documentation/teleo_user_guide/im... ). Browsing and selecting the right abstraction for the job is a lot simpler with this system.
By the way pdmtl's folder categorizing system is also compatible with Pd 0.4's help browsing system.
MB > Uh, my question actually is "why is _index.pd called an index?".
You are right. I will find a more proper name.
MB > I'd rather raise the issue before the [mapping] is even created.
A mapping category will not be created :)
On Mon, 2 Jul 2007, Thomas O Fredericks wrote:
We used "!" (an upside down "i" that stands for interface) before instead of "_"
"!" is used by Max to mean "swapped". IMHO that's a better idea than jMax's [inv+] and [inv*] meaning swapped [-] and [/] respectively, but GridFlow still uses jMax's syntax, for the obvious reasons.
but we had to continuously escape it in command lines and scripts. So we settled on "_" instead. Of course, we would have liked to use "#", but Gridflow's use of it is much better :)
I have been using the pmdtl folder namespaces for a year now and have NEVER had a similar problem. I tried replicating the example in a practical context, but I cannot. This issue is a theoretical problem that never happens in a practical context.
No, it's not theoretical, it's just false. There are problems that are similar to that, but knowing pd's implementation, I should've known better. See my mail to Patrice Colet today about this.
Why not put stuff outside of categories? (Does everything have to be in a category?)
Yes, everything does have to be in a category. This constraint makes for an environment that is especially useful for newbies and resolves a lot of conflicts.
verb/is article/this noun/sentence adjective/easier prep/to verb/read ?
I teach a lot of Max/Msp and the "new object" box is a godsend for them ( http://www.makingthings.com/teleo/products/documentation/teleo_user_guide/im... ). Browsing and selecting the right abstraction for the job is a lot simpler with this system.
What about http://artengine.ca/desiredata/gallery/completions2.gif ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, Jul 03, 2007 at 01:00:34PM -0400, Mathieu Bouchard wrote:
On Mon, 2 Jul 2007, Thomas O Fredericks wrote:
Why not put stuff outside of categories? (Does everything have to be in a category?)
Yes, everything does have to be in a category. This constraint makes for an environment that is especially useful for newbies and resolves a lot of conflicts.
verb/is article/this noun/sentence adjective/easier prep/to verb/read ?
Written english is quite different in application and parsing to objectboxes in the Puredata patching language. In my opinion the directory prefix adds to the understanding of what an objectbox is doing by adding context, whilst in your example above the context is inherent in the rules of the language and hence clumsy, confusing, and redundant. I think you are comparing apples and oranges, and the comparison is not a good argument against directory prefixes in object boxes.
What about http://artengine.ca/desiredata/gallery/completions2.gif ?
That is really cool.
Best,
Chris.
On Wed, 4 Jul 2007, Chris McCormick wrote:
On Tue, Jul 03, 2007 at 01:00:34PM -0400, Mathieu Bouchard wrote:
verb/is article/this noun/sentence adjective/easier prep/to verb/read ?
Written english is quite different in application and parsing to objectboxes in the Puredata patching language. In my opinion the directory prefix adds to the understanding of what an objectbox is doing by adding context, whilst in your example above the context is inherent in the rules of the language and hence clumsy, confusing, and redundant. I think you are comparing apples and oranges, and the comparison is not a good argument against directory prefixes in object boxes.
You are right about my comparison.
You are mostly right about what the prefixes do in pdmtl-abstractions. Whether each prefix is useful or not for a given object class, depends on what is one's ability to interpret the class name, but for some things it can be pretty automated: so far, every object class that has a "2" in the non-prefix part of its name, either go in category "convert" or category "musical". Whenever those are in category "musical", they would have been also candidates for "convert" but "musical" was picked instead. (the prefix system causes competition between intersecting categories)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, 2007-07-03 at 13:00 -0400, Mathieu Bouchard wrote:
On Mon, 2 Jul 2007, Thomas O Fredericks wrote:
Yes, everything does have to be in a category. This constraint makes for an environment that is especially useful for newbies and resolves a lot of conflicts.
verb/is article/this noun/sentence adjective/easier prep/to verb/read ?
Yes, but how do you resolve:
verb/colour noun/colour adjective/colour
or...
video/colour audio/colour
As humans we differentiate between these by their context, but PD is not that clever...
Jamie
To better understand the concept behind the pdmtl abstractions, please read the following: http://wiki.dataflow.ws/PdMtlAbstractions/Features
Also, the fact that the pdmtl abstractions uses a one depth folder category system seems to bother and confuse some, more than if the abstractions simply used a prefix .
Since the pdmtl abstractions are aimed for newbies and pro's alike, I am thinking that maybe I should change the categorizing system in the following manner (I kind of like how the abstractions look all sorted and neat in my file browser, but I never anticipated this could be a conceptual problem for some):
- separate the category name from the rest of the abstraction name with a "_"
while keeping the following rules:
- keep a limited number of categories (lets say not more than 30)
- also separate the rest of the words of an abstraction name with a "_"
I could adapt the pdmtl browsers so they still look like the newbie friendly max/msp object box.
What do you think (this question is aimed at the pd list, the pdmtl list and the pdmtl abstractions list)?
On 7/4/07, Jamie Bullock jamie@postlude.co.uk wrote:
On Tue, 2007-07-03 at 13:00 -0400, Mathieu Bouchard wrote:
On Mon, 2 Jul 2007, Thomas O Fredericks wrote:
Yes, everything does have to be in a category. This constraint makes for an environment that is especially useful for newbies and resolves a lot of conflicts.
verb/is article/this noun/sentence adjective/easier prep/to verb/read ?
Yes, but how do you resolve:
verb/colour noun/colour adjective/colour
or...
video/colour audio/colour
As humans we differentiate between these by their context, but PD is not that clever...
Jamie
On Wed, 4 Jul 2007, Jamie Bullock wrote:
On Tue, 2007-07-03 at 13:00 -0400, Mathieu Bouchard wrote:
verb/is article/this noun/sentence adjective/easier prep/to verb/read ?
Yes, but how do you resolve: verb/colour noun/colour adjective/colour
the verb could be written "colourise".
the verb could be prefixed with "to ", as an infinitive, while the noun wouldn't.
there is no adjective "colour", although like many nouns it can be used in several grammatical cases to form adjective-like prefixes such as in "colour-blind".
video/colour audio/colour
That is a good example; also there are several definitions of colour in use in video and/or visual arts. Colour is often assumed to be the information in a RGB pixel or equivalent, but sometimes it's assumed to include opacity as well. However, on my old telly, "COLOR" means "chroma gain" (saturation gain) instead, and that's also what "colour" means in Video4Linux1 digitiser settings. "Colour balance" usually means "chroma offset", nothing to do with luma and thus nothing to do with the whole of RGB, but not directly saturation either. In elementary school, our teacher was proud to teach us that "black and white are not REAL colours!".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hi,
2007/7/3, Mathieu Bouchard matju@artengine.ca:
On Mon, 2 Jul 2007, Thomas O Fredericks wrote:
I have been using the pmdtl folder namespaces for a year now and have NEVER had a similar problem. I tried replicating the example in a practical context, but I cannot. This issue is a theoretical problem that never happens in a practical context.
No, it's not theoretical, it's just false. There are problems that are similar to that, but knowing pd's implementation, I should've known better. See my mail to Patrice Colet today about this.
When inside an abstraction, let says foo/bar.pd, if you want to use an external that is named [bar], Pd complains : "error: bar: can't load abstraction within itself bar ... couldn't create"
And then, let say there is a "foo/counter.pd" in the same directory and that you wan to create a [counter], it will instanciate the "counter.pd" that is in that folder, and not the external that is in /usr/lib/pd/extra, for instance.
So yes, such a design is neither problems-free, nor a panacea, but so far our abstractions development has been overall facilitated a lot by the use of categories like these, and the Subversion repository that goto10.org is providing us.
Now, we'll change a few more things, and make it (finally) part of pd-extended. Don't hesitate to suggest a better suffix than "_" for the abstractions that provide a Graph-on-parent GUI, as we would like to change for a better one, if one exists. (maybe "$". "|", or "+", such as in "rgb$" or "rgb+" ?) Also, feel free to suggest some of your abstractions to be part of this.
By the way (regarding $args and $), I wrote a [flow/pak] that is a [pack] with all inlets hot ! (using dynamic patching)
Hello Alex,
Alexandre Quessy a écrit :
Now, we'll change a few more things, and make it (finally) part of pd-extended. Don't hesitate to suggest a better suffix than "_" for the abstractions that provide a Graph-on-parent GUI, as we would like to change for a better one, if one exists. (maybe "$". "|", or "+", such as in "rgb$" or "rgb+" ?) Also, feel free to suggest some of your abstractions to be part of this.
Two suggestions, using a familiar prefix might help for finding the good kind of abs, so 'x' might be a good prefix for graphical related patches, but the 'interface' is not involved by the 'x' prefix so 'gui' could simply give informations about interfacing, and using something like myabs-gui like it is done for help files, and would ease even more the finding of the abs function through the name, and, this naming would also help I believe, for having a 'gui function' with right click magiks on a patch, almost like it is done with help files (the difference is that this right click option would have to appear with clicking inside the patch), maybe it won't be usefull, may be it would...In fact it seems obvious to me that if some patch require an interface for being controlled, the minimum would be about providing the interface with it. Although it seem also obvious that one gui could control different kinds of dsp abstractions, so having a different gui for each dsp abs would not be the best choice, and make the task of interfacing (for both developper and user) not necessarily more complicated, but tiresome. PatCo.
On Thu, 5 Jul 2007, Alexandre Quessy wrote:
When inside an abstraction, let says foo/bar.pd, if you want to use an external that is named [bar], Pd complains : "error: bar: can't load abstraction within itself bar ... couldn't create"
This happens only when [bar] is not the name of an already-loaded external. If [bar] is loaded before [foo/bar] is, the above problem will not occur.
This kind of dependency on loading order is something that would usually be regarded as quite evil. It's sort of related to object numbering and wire numbering issues that are well known, but class loading order issues are the trickiest in that group of problems and the most difficult to get rid of.
And then, let say there is a "foo/counter.pd" in the same directory and that you wan to create a [counter], it will instanciate the "counter.pd" that is in that folder, and not the external that is in /usr/lib/pd/extra, for instance.
And yet, [/counter] will not pick up the toplevel [counter] name, because [counter] is looked up in -path, while [/whatever/the/name] never is. This is very much like the "shell" languages (bash, tcsh, ..., but not tclsh).
The filesystem<->namespaces mapping is very much varying from language to language, but usually, the thing called "namespace" is separate from the filesystem (e.g. C++,Tcl,Ruby) or maps to some kind of particular $PATH (e.g. Java), or is a "shell" language as defined above.
What I mean is that if Pd had "::" as in C++,Tcl,Ruby, then [::counter] would look for a prefixless "counter" but still in -path, as long as one is not already loaded. This could be the behaviour assigned to a plain "/" prefix, if one was willing to give up absolute folder names.
to change for a better one, if one exists. (maybe "$". "|", or "+", such as in "rgb$" or "rgb+" ?)
Even though $ as a suffix might be accepted by the current pd, I don't think it's a good idea to use it for anything else than variable substitution of some kind (either pd's or expr's).
By the way (regarding $args and $), I wrote a [flow/pak] that is a [pack] with all inlets hot ! (using dynamic patching)
[#pack] is also all-inlets-hot.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Alexandre Quessy -
Chris McCormick -
Frank Barknecht -
IOhannes m zmoelnig -
Jamie Bullock -
Luke Iannini (pd) -
Mathieu Bouchard -
Patco -
Thomas Grill -
Thomas O Fredericks