Re: [PD] pdmtl abstractions questions and comments (previously without a subject)
that's a great idea there! thanks for that one. Thomas O Fredericks <[EMAIL PROTECTED]> wrote: > Also, since the "_" > abstractions simply wrap their counterparts, they are both > automatically updated if the "engine" is updated. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
Hi, 2007/7/3, Mathieu Bouchard <[EMAIL PROTECTED]>: > 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) -- Alexandre Quessy http://alexandre.quessy.net http://www.puredata.info/Members/aalex ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
On 7/4/07, Thomas Grill <[EMAIL PROTECTED]> wrote: He's back! greetings, Thomas I am glad about it : ) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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 <[EMAIL PROTECTED]> 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 > > -- thomas ouellet fredericks, [EMAIL PROTECTED], montreal, canada ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > >If someone else does an abstraction collection for lists, I'd say, > >"list_" or "list." are two other good choices. > > So far, Max seems to be using ".", for example "jit."; because of this, > I've used the "." prefix but for "lti." classes; actually I also used it > for some PureUnity classes, initially like "f." "~." "#." to mean float's, > signal's, grid's, in a way that is meant to be used as [$1.hello]. I have > changed this to around to [hello.$1] because of pd 0.40 and of personal > preference. There is a minor annoaynce with the dot for abstractions ATM because of an unfixed bug: If you save a new abstraction that already has a dot in its name like "list.abs", you need to add the ".pd" extension manually, otherwise Pd will save it as "list.abs" instead of "list.abs.pd". This is not a problem with "list-abs" which gets the suffix added automatically by Pd. > >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. > > Edit the five source files, changing the name in it for something else. Is > that so impossible? It might not be pretty, but I wouldn't call it > "impossible". Well, but then you wouldn't have five objects named [counter] anymore. And of course there is the social problem: How is it decided, which counter should keep its name? And that is actually what I meant with this: > >All this to me seems to kind of pervert what Guenther Geiger actually > >intended when suggesting directory prefixes and initiating the > >CVS-repository. IIRC one motive to start the CVS was to get rid of objects that do slightly different things but have the same name (like the [counter]s) by first collecting them all in one place (Sourceforge), see what's duplicated and/or conflicting, and then decide on the one "real" counter - possibly keeping the four others with different names. Unfortunatly we didn't get further with developing an infrastructure to decide things like that. > Actually, it never occurred to me that those two things were related. I > think that I joined pd-list shortly after the CVS created, but I don't > recall that anyone said (in the last five years of pd-list) that the whole > externals/ thingie had to do with Geiger namespaces. The namespace and the CVS are not related directly, I didn't want to imply that. Geiger namespaces are just way to keep the four other [counter]s from above available, in case someone needs them. However I fear, that they also became a kind of excuse to not think about developing a way to decide things like "which [counter] to keep". > >and the "Path" window is filled with more entries than it can handle. > > Apart from what the intention might have been about paths or libs > (libdirs), this is not a problem with Hans's work per se, it's a problem > in u_main.tk, and it's very possible to fix it: e.g. > http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user > interface also exists for -path and -helppath separately. Of course one could easily overhaul the path windows (and one has to do it for plain Pd as well) to be able to handle more paths, but the actual problem is: Why are there so many paths and are they all really necessary? > >[list-abs/list-abs] is bit-rot. > > Well, i've only seen the word "bit-rot" to mean things that result from > not updating software to changing interfaces (I'm not counting the meaning > of it that has to do with physical media). Thus I don't really know what > you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] > has gone unmaintained for years such that the definition of pd (or what pd > is in practice) has changed such that is has become contextually broken or > outdated or irrelevant... I meant: Using [list-abs/list-abs] instead of just [list-abs] is a kind of bit rot, because the more people use the double or triple prefix, the more it gets carved into (some) stones and at some point, users will expect the [list]-abs objects with long names to be available. Maybe that's not something to call bit rot, but it would be rotten. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments (previously without a subject)
> > 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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/images/max_tut_1_new.png ). 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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
On Tue, 3 Jul 2007, Alexandre Quessy wrote: 2007/7/3, Mathieu Bouchard <[EMAIL PROTECTED]>: 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&group_id=55736&atid=478072 _ _ __ ___ _ _ _ ... | 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
Re: [PD] pdmtl abstractions questions and comments
Alexandre Quessy wrote: > Hi, > > Nice conversation. :) > > 2007/7/3, Mathieu Bouchard <[EMAIL PROTECTED]>: >> 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
Hi, Nice conversation. :) 2007/7/3, Mathieu Bouchard <[EMAIL PROTECTED]>: > 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 http://alexandre.quessy.net http://www.puredata.info/Members/aalex ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments (previously without a subject)
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" c
Re: [PD] pdmtl abstractions questions and comments
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__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
> [...] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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/images/max_tut_1_new.png ). 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 befor
Re: [PD] pdmtl abstractions questions and comments
I vote for "_". There is two perspectives: the user, and the developer of pd. Often the user don't need to know about the exactly folder's tree. A good documentation eschew the mess 2007/7/2, victor <[EMAIL PROTECTED]>: I vote for "_". There is two perspectives: the user, and the developer of pd. Often the user don't need to know about the exactly folder's tree. A good documentation eschew the mess 2007/7/2, Thomas O Fredericks <[EMAIL PROTECTED]>: > > > 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 > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
> 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
> 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, That's on my todo list for the py/pyext external, but it's not at top level. greetings, Thomas ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdmtl abstractions questions and comments
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__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.p
