hi, this is gonna sound like a dumb question but, is there an appropriate place for me to put gem pd's/pd_linux and motex pd's in linux? do i hav to put anything in /usr/bin? -thanks :) a linux_newbie/pd_newbie, mark k.
Mark Khemma hat gesagt: // Mark Khemma wrote:
this is gonna sound like a dumb question but, is there an appropriate place for me to put gem pd's/pd_linux and motex pd's in linux? do i hav to put anything in /usr/bin?
No, don't put anything besides pd, pdsend and pdreceive in /usr/bin The two 'official' places are /usr/lib/pd/externs and /usr/lib/pd/extra,
[if someone could explain the difference, I'd like to know why there are two standard directories in the PD distribution.]
But you can also put them in any directory, that you have in you "pd-path", i.e. all directories after the "-dir" command line of conf. file option of PD.
The PD path has nothing to do with the standard search patch for executable binaries i.e. the environment variable PATH that you see with "echo $PATH"
ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
Frank Barknecht wrote:
Mark Khemma hat gesagt: // Mark Khemma wrote:
The two 'official' places are /usr/lib/pd/externs and /usr/lib/pd/extra,
[if someone could explain the difference, I'd like to know why there are two standard directories in the PD distribution.]
it's quite simple (i believe): guenter started his linux port of pd with this pd/externs folder that was searched automatically (?) miller then adopted this idea, but unfortunately chose pd/extra as a standard search-path. so in a "normal" (miller) pd-distribution you should only have a pd/extra path. in a debianized distribution (guenter) you will have the (now additional) pd/externs. distributions modified at iem are likely to be derived from guenter's.
anyhow, there is no reason to have two different directories for the same purpose. additionally, the pd/externs directory is not searched by default, so users have to add the search-path to there .pdrc/startup-script by hand anyway if they want to use it.
i am not sure, whether it really is a good idea, to use the pd/extra for normal libraries such as Gem,... i would prefer (but i admit: it's mainly for historical reasons, since most of our pc's here are already setup with this ominous pd/externs folder) three independant search-paths (instead of two), with a clear policy:: -- pd/extra : for extras that ship with pd (toys, like fiddle~,... everything that is in the pd/extra by default now); it should *not* be touched by add-on installations (see below) -- pd/externs : for add-on external libraries (such as motex, ggee,...) and only libraries (only *.dll/*.pd_linux/*.pd_irix) -- pd/abs : for add-on abstractions (such as parts of the iemlib-library)
mfg.cd.sar IOhannes
On Mon, 11 Mar 2002, IOhannes m zmoelnig wrote:
policy:: -- pd/extra : for extras that ship with pd (toys, like fiddle~,... everything that is in the pd/extra by default now); it should *not* be touched by add-on installations (see below) -- pd/externs : for add-on external libraries (such as motex, ggee,...) and only libraries (only *.dll/*.pd_linux/*.pd_irix) -- pd/abs : for add-on abstractions (such as parts of the iemlib-library)
The problem I see with this is, if someone writes an external, or extents and existing one, and chooses the same name because it fits so well, we get name clashes inside externs.
This is an argument for always packageing externals into libraries, but on the other hand it makes it very unflexible because it is not possible to load two libraries with the same external.
Another solution is putting the externals into subdirectories e.g /usr/lib/pd/externs/zexy.
externals then can be loaded with object |zexy/furb|, or if someone preferres to use |furb| only it can be copied into the working directory or added to the -path switch etc.
same for abstractions, ...
but I am not really sure if a system like that really works in practice ?
Guenter
Hi Guenter and Iohannes,
I think the best thing is to throw everything in pd/extra. This will mean that updating Pd requires that you reassemble the externs, but then, at some level you always will have to do that, so it probably doesn't help to have two or three such directories instead of one...
cheers Miller
On Mon, Mar 11, 2002 at 06:43:16PM +0100, günter geiger wrote:
On Mon, 11 Mar 2002, IOhannes m zmoelnig wrote:
policy:: -- pd/extra : for extras that ship with pd (toys, like fiddle~,... everything that is in the pd/extra by default now); it should *not* be touched by add-on installations (see below) -- pd/externs : for add-on external libraries (such as motex, ggee,...) and only libraries (only *.dll/*.pd_linux/*.pd_irix) -- pd/abs : for add-on abstractions (such as parts of the iemlib-library)
The problem I see with this is, if someone writes an external, or extents and existing one, and chooses the same name because it fits so well, we get name clashes inside externs.
This is an argument for always packageing externals into libraries, but on the other hand it makes it very unflexible because it is not possible to load two libraries with the same external.
Another solution is putting the externals into subdirectories e.g /usr/lib/pd/externs/zexy.
externals then can be loaded with object |zexy/furb|, or if someone preferres to use |furb| only it can be copied into the working directory or added to the -path switch etc.
same for abstractions, ...
but I am not really sure if a system like that really works in practice ?
Guenter
hi all,
may I throw in a few rambling questions and thoughts?
If I would ever want to provide install option in any release of my libraries, am I supposed to make that into the `official' place, be it /usr/(local/?)lib/pd/extra, or whatever? With all the symlinks accompanying library file (like xeq_parse.pd_linux->xeq.pd_linux)?
Well, I would hesitate to do that -- keeping all externs in a single flat directory. I would rather put my stuff somewhere down the tree.
I see two ways:
- Reserve the `official' flat directory for a small set of
`officially approved' libraries. Unofficial add-ons may go into whatever other place their author chooses, preferably into subdirectories of .../pd/extra, but the place has to be always -path-added into .pdrc (how about Windows users?)
- Design an optional tree-searching (or full-blown globbing)
mechanism for open_via_path() to be used whenever loading libraries (and possibly abstractions) is involved.
The second, which is much better, is probably only a dream.
And surely all of the above is totally wrong, as I have never `installed' Pd, or any of its libraries yet. Always been working with their source trees (yes, also in a multiuser environment, with other users reading my /home... what a shame...)
Krzysztof
Miller Puckette wrote: ...
I think the best thing is to throw everything in pd/extra. This will mean that updating Pd requires that you reassemble the externs, but then, at some level you always will have to do that, so it probably doesn't help to have two or three such directories instead of one...
Hi,
for Windows (maybe it works for Linux too) I could imagine using an environment variable, e.g. PD_EXTRA (like "VST_PATH" which is used for VST Plug-Ins). There could be batch files included with externals that add the correct path to the list (or it could be done manually by the user). The command would be something like:
"set PD_EXTRA=c:\pd\etxra;c:\pdogg~;c:\path\to\other\externals"
This could also be implemented for help patches...
Olaf
Krzysztof Czaja schrieb:
I would rather put my stuff somewhere down the tree.
Krzysztof
Miller Puckette wrote: ...
I think the best thing is to throw everything in pd/extra. This will mean that updating Pd requires that you reassemble the externs, but then, at some level you always will have to do that, so it probably doesn't help to have two or three such directories instead of one...
hi again,
after taking a closer look, I rejected my original tree-searching idea. It is probably not worth the fuss, because it cannot be done well with any simple kind of path-walking performed during loading of a library. If my (hazy) idea was to be rendered into a real design, there would need to be an extra knowledge used -- gathered beforehand. This preprocessing is needed both to speed up the search, somewhat like locatedb or ls-R of texhash, and to filter out obsolete versions, resolve name clashes, etc.
So if there was to be a kind of personalized pdb on every Pd user's hard disk, why not to design a standard mechanism for registering libraries with a version number, and a full list of external classes: their names, help file locations, `assistance' descriptions, links to reference pages, etc.
This user-pdb or system-pdb could be updated during library installation pass, and then consulted by the sys_load_lib() call in Pd -- before or after or instead of searching .../pd/extra and the -paths.
The next step would be to connect user-pdb to graz-pdb (or mirrors) ala deb :)
|
Krzysztof Czaja wrote: ...
flat directory. I would rather put my stuff somewhere down the tree.
...
- Design an optional tree-searching (or full-blown globbing)
mechanism for open_via_path() to be used whenever loading libraries (and possibly abstractions) is involved.
two naive but related questions:
- where would i find/make a .pdrc?
1a) how would a write a .pdrc script (syntax)? 2) where should i put gem packages thanks, -mark k. On Mon, 11 Mar 2002, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Mark Khemma hat gesagt: // Mark Khemma wrote:
The two 'official' places are /usr/lib/pd/externs and /usr/lib/pd/extra,
[if someone could explain the difference, I'd like to know why there are two standard directories in the PD distribution.]
it's quite simple (i believe): guenter started his linux port of pd with this pd/externs folder that was searched automatically (?) miller then adopted this idea, but unfortunately chose pd/extra as a standard search-path. so in a "normal" (miller) pd-distribution you should only have a pd/extra path. in a debianized distribution (guenter) you will have the (now additional) pd/externs. distributions modified at iem are likely to be derived from guenter's.
anyhow, there is no reason to have two different directories for the same purpose. additionally, the pd/externs directory is not searched by default, so users have to add the search-path to there .pdrc/startup-script by hand anyway if they want to use it.
i am not sure, whether it really is a good idea, to use the pd/extra for normal libraries such as Gem,... i would prefer (but i admit: it's mainly for historical reasons, since most of our pc's here are already setup with this ominous pd/externs folder) three independant search-paths (instead of two), with a clear policy:: -- pd/extra : for extras that ship with pd (toys, like fiddle~,... everything that is in the pd/extra by default now); it should *not* be touched by add-on installations (see below) -- pd/externs : for add-on external libraries (such as motex, ggee,...) and only libraries (only *.dll/*.pd_linux/*.pd_irix) -- pd/abs : for add-on abstractions (such as parts of the iemlib-library)
mfg.cd.sar IOhannes
do this: vim/vi/emacs ~/.pdrc (pick whatever your text editor is) then you can type into the file any command line switches you would use with pd. ie:
-r 44100 -font 10 -path /path/to/externs1:/path/to/externs2/:/path/to/abstractions1 -lib /path/to/gem -lib /path/to/ext13 etc...
(BTW, .pdrc should not include any comments)
gem (or any lib/extern) can go to any place on your system as long as you specify the -path (to externs) and/or -lib (path to the lib)
usually the "make install" procedure will put things in the right places (but you will have to specify the lib path by hand) although I noticed that by default PD is installed /usr/local/lib/pd and some of the externs out there use /usr/local/pd as default. Check configure scripts and/or Makefile for default installation locations.
./MiS
Mark Khemma wrote:
two naive but related questions:
- where would i find/make a .pdrc?
1a) how would a write a .pdrc script (syntax)? 2) where should i put gem packages thanks, -mark k.
On Mon, 11 Mar 2002, Mark Khemma wrote:
- where would i find/make a .pdrc?
use your favourite text editor, save it as '.pdrc' in your user folder (/usr/local/you/.pdrc)
1a) how would a write a .pdrc script (syntax)?
-rt -midiindev 1 /* or whatever
-lib /* path to whatever libs you compile -path /* to /usr/lib/extra or /externs or in fact wherever you want pd to search for stuff
check out more options in the docs, section 'how to start pd'
DC
david casal --0+
d.casal@uea.ac.uk --9+
www.ariada.uea.ac.uk/~dcasal --)+
-
david casal -
Frank Barknecht -
g�nter geiger -
IOhannes m zmoelnig -
Krzysztof Czaja -
Mark Khemma -
Michal Seta -
Miller Puckette -
Olaf Matthes