Thanks for that concise write-up. I think dealing with externals was never so stringent before as it is now. What I really appreciate is that going with defaults all along creates a sensible setup.
Roman
On Thu, 2021-02-25 at 10:18 +0100, Dan Wilcox wrote:
Howdy Phil,
We are moving away from the "extra" folder and additional "standard paths" like ~/.pd-externals in favor user search paths for most use cases. This requires specifying folders, so a helper "Documents Directory" was added, mainly for beginners and students but I find it generally useful. For those that don't, it can simply be ignored and disabled.
I think the info on this was updated in the included Pd manual by Alex, but off the top of my head the simplest explanation is the following:
If not enabled, enable the Pd Documents Directory:
Preferences -> Path... -> Pd Documents Directory -> Reset
There should now be a ~/Documents/Pd/externals folder which is also added to the user search paths.
Put external library folders in there, deken also downloads to here by default.
Note: You can of course use your own user search path and set the path deken downloads to, in which case the following info still applies.
You can now find externals in this folder using [declare]. If you have an external called "extname" in the following folder:
~/Documents/Pd/externals/extname
It should be found by Pd with: [declare -path extname -lib extname]
The -path argument specifies search paths while -lib specifies a location to try to load compiled externals, so some externals may require both while abstraction-only externals should only require -path. More complicated externals like Gem which also need to load addition dynamic libs should also work, although may require additional steps / folder placement.
Note: once compiled externals are found and loaded, they cannot be unloaded or reloaded.
Also, without using [declare], objects can be found in the user search paths via prepending the external's folder name:
[extname/foobar]
Last, if the path given to declare starts with a . or .. (ie. it's a relative path), the search mechanism only looks *relative* to the patch and does not look in further user search or standard paths. This should help encapsulation of certain projects.
[declare -path ./extname]