Hallo, Thomas Mayer hat gesagt: // Thomas Mayer wrote:
It's working now. Here is my solution
find /usr/local/lib/pd -name svf* gives:
/usr/local/lib/pd/doc/examples/cyclone/svf-test.pd /usr/local/lib/pd/extra/bsaylor/svf~.pd_linux /usr/local/lib/pd/extra/cyclone/svf~.pd_linux /usr/local/lib/pd/extra/flatspace/svf~.pd_linux
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~:
- 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.
- 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.
- 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.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__