[PD] missing externals after compilation
fbar at footils.org
Mon Oct 9 13:04:31 CEST 2006
Thomas Mayer hat gesagt: // Thomas Mayer wrote:
> It's working now. Here is my solution
> find /usr/local/lib/pd -name svf\* gives:
> only /usr/local/lib/pd/extra/ is in the startup searchpath. After
> copying the files from the directory bsaylor into the
> /usr/local/lib/pd/extra/ directory, svf~ is available. dito for aenv~.
> Maybe Pd doesn't use subdirectories or has a problem with more than one
> version of a file.
Pd does have a problem with more than one version: This is called a
nameclash. Here you have three svf~.pd_linux files, and probably they
all behave differently. pd-extended doesn't force you to use a
specific one, because it might be the wrong one. So pd-extended puts
all of them in their own subdirectories out of view of Pd.
You can do things to activate a specific sfv~:
1) move one file into your path like you did.
pro: easy and traditional
contra: you can only move one file like this, updates won't get
noticed unless you move the updated files again, you cannot use the
other svf~'s like this.
2) adapt your path to include the directory, the file is located using
-path or -libdir or the new [declare] object (later).
pro: will survive updates. settings are in a central location
(pdsettings/pdrc), more flexible than moving because of this.
contra: has to be done for many objects and by many users.
3) include the path in the object name like [cyclone/svf~] or
[bsaylor/svf~]. Parent directory has to be in you path already, but
"extra" always is.
pro: you directly see which sfv~ you're using. You can (maybe) use
both external-versions in one patch. Avoids nameclashes.
contra: You introduce new, longer names, that non-users of
pd-extended can only guess. Old patches need to be adapted.
Help-patches may not work fully.
Choose your poison.
Frank Barknecht _ ______footils.org_ __goto10.org__
More information about the Pd-list