Hi friends, we are finalizing APODIO version 4 for audio & video : http://www.apodio.org our last challenge is PD and the integration of a maximum of the librairies available... We are actually experimenting different way to generate a .pdrc from a choice people will do of the librairies they want to use...and put in the .pdrc... As you maybe know the librairies integration is quite messy... for some ;-)
I would like to ask to you what's your best .pdrc you have, that we could use as exemple!!!
I mean for percolate, zexy or maxlib it's quite easy but for some other where each objects correspond to a librairies machin.pd_linux it's quite a job... so if you have a clean and well made .pdrc please could you send it on the list.
thanks a lot
Juto
Hallo, juto aviten hat gesagt: // juto aviten wrote:
I mean for percolate, zexy or maxlib it's quite easy but for some other where each objects correspond to a librairies machin.pd_linux it's quite a job...
Huh? If you have an object like xyz.pd_linux and its only object is "xyz" then this xyz.pd_linux is not a library, but a single external and you should *not* add "-lib xyz".
so if you have a clean and well made .pdrc please could you send it on the list.
.pdrc is .pdsettings now (or soon).
For the Rotterdam workshop at V2 we did it simple: First we used scons to build all externals. There were some problems:
toxy needs to find the tcl/tk headers, which can be fixed by changing the main scons file in the build directory to hardcode the path, but that's a bit hacky. Better would be to write a real check for tcl/tk headers.
pdogg doesn't link with the ogg/vorbis libraries. SCons-Fu is needed here, too.
You can specify the prefix to install using a file "custom.py" which includes:
prefix = "/usr/lib/pd"
if you don't want to install to /usr/local.
After "scons install" everything is in /usr/lib/pd/extra which is good, as you then would only need to set up one path.
Scons doesn't deal with flext-externals yet, so do this by hand.
As for libraries, most of the objects are also available as single externals, if you use the scons build. This includes zexy, iemlib*, cyclone etc. but not iemmatrix. Iemmatrix is very useful, so built it by hand. Also maxlib externals are built as single externals.
Actually the machines at the workshop didn't use a single library at all, as everything was available, that we needed. The only thing we added was pdogg, because of the linking problem, which we fixed at that time by using the upstream Makefile, that builds a library.
On my own machine, I still have this in .pdrc:
-lib iemlib1:iemlib2:iem_t3_lib:iem_mp3:iemmatrix:PDContainer -lib pmpd:Gem:py -lib OSC:zexy:xsample:maxlib:creb:ratts
but some of this is cruft, as e.g. creb externals are also available a single externals in my /usr/lib/pd/extra
Special care has to be taken with abstractions, that relate to libraries. Most important here probably is "iemabs" which includes useful wrappers such as "any.pd". You could just install these to /usr/lib/pd/extra as well and instead of messing with adding a new path, just go drink a cold beer in the warm late summer evening.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Huh? If you have an object like xyz.pd_linux and its only object is "xyz" then this xyz.pd_linux is not a library, but a single external and you should *not* add "-lib xyz".
well, "should *not*" should say "won't have to" ;-)
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
Huh? If you have an object like xyz.pd_linux and its only object is "xyz" then this xyz.pd_linux is not a library, but a single external and you should *not* add "-lib xyz".
well, "should *not*" should say "won't have to" ;-)
true, but well++, I wanted to stress this point: If you're preconfiguring a package as a distribution maker, you should not load every single external as a lib, but just set the path. If a user wants to preload a single object using -lib, this is some personal preference but should not be done by the distribution. IMHO.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
true, but well++, I wanted to stress this point: If you're preconfiguring a package as a distribution maker, you should not load every single external as a lib, but just set the path. If a user wants to preload a single object using -lib, this is some personal preference but should not be done by the distribution. IMHO.
Yes that's the point we are actually debate... so if you want to include in the path librairies like unauthorized, ext13, cyclone...etc which have a binaries (externals?) for each objects include in the lib... and that you want to create a script where people choose the externals/lib available to include in the pdsettings ;-) , how you do that? do you include that in a path like /usr/lib/pd/externals/ext13 ...etc and then -lib ext13 but then it don't load all the binaries of the lib (externals?)... . The script is made like this : it go to find librairies in a path like this one /usr/lib/pd/externals and then upload to a graphic window and let's people choose which lib they want to include in their pdsettings... but for maxlib, percolate...no problem because they have one binary for all the objects in the lib... but for others lib the script show all the objects of the lib and then the script write the path & -lib tata (name of the binary.externals) including -lib alltheobjectsofthislib... if you guys have some ideas...
cheers
julien
Hallo, juto aviten hat gesagt: // juto aviten wrote:
Yes that's the point we are actually debate... so if you want to include in the path librairies like unauthorized, ext13, cyclone...etc which have a binaries (externals?) for each objects include in the lib... and that you want to create a script where people choose the externals/lib available to include in the pdsettings ;-) , how you do that? do you include that in a path like /usr/lib/pd/externals/ext13 ...etc and then -lib ext13 but then it don't load all the binaries of the lib (externals?)... .
The solution is: Don't use libraries at all, where not necessary! I lined out a way to achieve this in my first mail: use scons. That way, you don't get ext13.pd_linux, but all externals, that would be bundled into the ext13 library, became single externals instead. This way you don't need to use "-lib ext13" at all, while users would still have all ext13 objects available.
This works for most libraries except a few like iemmatrix or bigger ones like Gem. There are only about half a dozen libraries, which cannot be build (resonably) as single externals.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
juto aviten -
Tim Blechmann