I'd like to propose an idea for organizing all of the objects, instead of placing everything directly in "extra" and "doc/5.reference". Everything that is aimed to be a standard part of Pd would go in "extra" and "5.reference". Then objects that have conflicted names, objects that are deprecated, or cyclone/Max-compatibility objects would go into their own folders. When someone wants to use these objects, they can add then directories using -path and -helppath.
Here's an outline:
- "cyclone" objects that are only for Max compatibility ([Borax~], [coll], [mousefilter], etc.) T
- For name conflicts, there would be library-specific folders: - "gem" [counter], [scale], [average], [change] - "cxc" [prepend], [counter], [split] - "iem" [gate], [prepend], [speedlim] - "maxlib" [speedlim], [borax], [scale], [split]
- "deprecated" would be for deprecated objects, like [linuxjoystick], etc. - there could be subdirectories for specific things like "Gem"
I think this layout would solve a number of problems, and be relatively easy to implement.
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Zitiere Hans-Christoph Steiner hans@eds.org:
I'd like to propose an idea for organizing all of the objects, instead of placing everything directly in "extra" and "doc/5.reference". Everything that is aimed to be a standard part of Pd would go in "extra" and "5.reference". Then objects that have conflicted names, objects that are deprecated, or cyclone/Max-compatibility objects would go into their own folders. When someone wants to use these objects, they can add then directories using -path and -helppath.
correct me if i am wrong: 1) let's assume wwe have a libraray "foo", containing of foo.pd_linux and a number of help patches foo-help.pd and bar-help.pd; _now_ these files are in /usr/lib/pd/extra/: /usr/lib/pd/extra/foo.pd_linux, /usr/lib/pd/extra/foo-help.pd and /usr/lib/pd/extra/bar-help.pd you _propoese_ them to be in /usr/lib/pd/foo/ or in /usr/lib/pd/extra/foo ?? - the first solution would impose a bad thing on the usability of pd (in my opinion): up till now, you can specify the libraries you want to be loaded in the patch itself, without having to hazzle with command-line arguments or rc-files: this is ok if you have only one evironment you work with, but if you want "several different pds-flavours" (libraries loaded,...) you would need to eliminate (or strip down) you rc-file and write quite long .BAT-fies (notice that the use of .BAT is on pupose as i really think this is old, clumsy and should be deprecated, especially with respect to the new console-less pd) - the second solution is already implemented in pd (i think), so people would just need to use it (which thy should do anyhow and which makes your proposal not at all "useless")
2) problems with libraries containing mulitple so-files and pd-files are a bit more complicated (so i guess you are refereing to that) i really think that the solution with giving a lot of path-names is _not_ good, because (as mentioned before) we are not (yet ?) able to add things to the search-path from within the patch (probably we are, with some weird messages) but anyhow, then we would need knowledge about the directory-layout on the harddisc which is a bad thing too) BUT: using your layout (without adding -path !) would enforce people to use our all-time favourite "namespaces" which is indeed a good thing.
so as a conclusion: i think too that libraries should go into separate directories, AND i think that these directories should be in pd/extra
mfg.ads.r IOhannes
On Dec 17, 2004, at 3:01 AM, zmoelnig@iem.at wrote:
Zitiere Hans-Christoph Steiner hans@eds.org:
I'd like to propose an idea for organizing all of the objects, instead of placing everything directly in "extra" and "doc/5.reference". Everything that is aimed to be a standard part of Pd would go in "extra" and "5.reference". Then objects that have conflicted names, objects that are deprecated, or cyclone/Max-compatibility objects would go into their own folders. When someone wants to use these objects, they can add then directories using -path and -helppath.
correct me if i am wrong:
- let's assume wwe have a libraray "foo", containing of foo.pd_linux
and a number of help patches foo-help.pd and bar-help.pd; _now_ these files are in /usr/lib/pd/extra/: /usr/lib/pd/extra/foo.pd_linux, /usr/lib/pd/extra/foo-help.pd and /usr/lib/pd/extra/bar-help.pd you _propoese_ them to be in /usr/lib/pd/foo/ or in /usr/lib/pd/extra/foo ??
- the first solution would impose a bad thing on the usability of pd
(in my opinion): up till now, you can specify the libraries you want to be loaded in the patch itself, without having to hazzle with command-line arguments or rc-files: this is ok if you have only one evironment you work with, but if you want "several different pds-flavours" (libraries loaded,...) you would need to eliminate (or strip down) you rc-file and write quite long .BAT-fies (notice that the use of .BAT is on pupose as i really think this is old, clumsy and should be deprecated, especially with respect to the new console-less pd)
- the second solution is already implemented in pd (i think), so
people would just need to use it (which thy should do anyhow and which makes your proposal not at all "useless")
- problems with libraries containing mulitple so-files and pd-files
are a bit more complicated (so i guess you are refereing to that) i really think that the solution with giving a lot of path-names is _not_ good, because (as mentioned before) we are not (yet ?) able to add things to the search-path from within the patch (probably we are, with some weird messages) but anyhow, then we would need knowledge about the directory-layout on the harddisc which is a bad thing too) BUT: using your layout (without adding -path !) would enforce people to use our all-time favourite "namespaces" which is indeed a good thing.
so as a conclusion: i think too that libraries should go into separate directories, AND i think that these directories should be in pd/extra
I am not thinking at all about libraries because I think that externals should be distributed as individual objects, and I plan on making that happen in the distros that I work on. As far as I know, the only advantage that libraries currently have is shared code. I am going to try my hand at implementing Günter's idea of having a shared library for the shared code, while the objects are in individual files. Thomas Grill was working on this for flext also, I think he got it working.
One thing that I forgot to mention (which you did mention) is that you could also use the namespace to access these objects without adding anything to the path. For example, to use a deprecated object you would do this:
[deprecated/linuxjoystick /dev/input/event2]
So putting "../extra/deprecated" in the path would only be for porting the patch. Though this is much less necessary now that 0.38 will maintain the connections when an object can't be found.
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
I am not thinking at all about libraries because I think that externals should be distributed as individual objects, and I plan on making that
yes, i know that, so that is why i have written point-2 (with "i guess that is what you are talking about")
One thing that I forgot to mention (which you did mention) is that you could also use the namespace to access these objects without adding anything to the path. For example, to use a deprecated object you would do this:
[deprecated/linuxjoystick /dev/input/event2]
So putting "../extra/deprecated" in the path would only be for porting the patch. Though this is much less necessary now that 0.38 will maintain the connections when an object can't be found.
there i just one thing i want to point at (and this is somewhat important to me, an _please_ do not shrug off my problems with "you are the only one who needs this, so we should stop this discussion" as i have the feeling with my rc-file requirements everytime it comes to this ;-)): please do not rely on the "-path" command-line flag. there are (certainly) a lot of situations where you can neither edit BAT-files nor rc-files for your need. (i mean, as a packager who does not know the exact layout of the end-user's system)
just to reinforce my point of view.
and upgrading with the -path options seems tolerable to me. although i don't think that the connection-maintainance of 0.38 substitutes this: i mean, when you open your patch for the sole purpose of upgrading then it is surely ok, but most probably people would just keep their old patches running...
mfg..asdr IOhannes
Hans-Christoph Steiner wrote: ...
- "cyclone" objects that are only for Max compatibility ([Borax~],
[coll], [mousefilter], etc.) T
that is fine, although max compatibility requires, currently, starting Pd with -lib maxmode option -- which loads all cyclone classes (packaged into libraries), and adjusts their behaviour.
Krzysztof
On Dec 17, 2004, at 11:35 AM, Krzysztof Czaja wrote:
Hans-Christoph Steiner wrote: ...
- "cyclone" objects that are only for Max compatibility ([Borax~],
[coll], [mousefilter], etc.) T
that is fine, although max compatibility requires, currently, starting Pd with -lib maxmode option -- which loads all cyclone classes (packaged into libraries), and adjusts their behaviour.
Then it makes sense to keep cyclone as a library, then take the generally useful objects like [prepend] out of the cyclone library, and add them somewhere else as individual objects. This would make name conflicts much easier to deal with. Miller talked at pd~conf about adding some of the cyclone objects to the Pd core.
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
-
Hans-Christoph Steiner -
Johannes M Zmoelnig -
Krzysztof Czaja -
zmoelnig＠iem.at