Please find a detailed tutorial on managing and installing Pd externals here.

This FAQ entry is a more objective and simple guideline that should be ok for most cases.

There are special folders for installing libraries, externals, object classes, abstractions, GUI plugins, and help files into. These folders are for things that are not included in the Pd binary. A more detailed discussion on using and installing libraries with Pd vanilla and its library manager Deken can be found here.

On all platforms, there is a user-specific system folder, an application-specific folder and a global system folder. The global system folder affects all Pure Data Applications for all users. You will require administrator priviliges to be able to install things into those folders. The User-specific system folder affects all Pure Data Applications for that user. The system folder allows you to upgrade Pd without messing up your other files. And since you can have different versions of Pd installed in your system, the Application-specific folder affects only that particular Pd Application. This can be not only an older and a newer version, but also both 32-bit and 64-bit versions available for Mac OS, and even Pd Extended!

At the time of writing (2017-07-29), most of these directories will not get automatically created. Once you have created these folders, Pd will start using them (this probably requires a restart of Pd).

GNU/Linux

Many externals can be installed through the package manager in Debian/Ubuntu/Mint. The Packages have a pd-... prefix.

Application-specific

typically /usr/lib/pd/extra if you installed Pd via a package manager (such as apt) or /usr/local/lib/pd/extra if you compiled Pd yourself.

User-specific

~/.local/lib/pd/extra (since Pd-0.47-1, preferred) or ~/pd-externals (deprecated/older Pd-versions; still usable)

Global

/usr/local/lib/pd-externals

Mac OS X

Application-specific

typically /Applications/Pd.app/Contents/Resources/extra (This is inside the Pd Application. First you need to find the Pd App (usually in /Applications), then right click and choose “Show Package Contents”).

User-specific

~/Library/Pd

Global

/Library/Pd

Windows

Application-specific

typically %ProgramFiles(x86)%\Pd\extra (for 64-bit systems) or %ProgramFiles%\Pd\extra (for 32-bit systems); this is inside the Pd Application, usually in C:\Program Files (x86) for 64-bits.

User-specific

%AppData%\Pd (since Pd-0.47)

• %AppData%\Pd will be something like C:\Users\myusername\AppData\Roaming\pd
• prior to Win7 (e.g. Vista, XP, Win2000) this was synonymous with %UserProfile%\Application Data\Pd (which was used before Pd-0.47)

Global

%CommonProgramFiles%\Pd

• on an English system, this is usually C:\Program Files\Common Files\Pd
• en español: \Archivos de programa\Archivos comunes\Pd
• auf Deutsch: \Programme\Gemeinsame Dateien\Pd
• this is mostly synonymous for %ProgramFiles%\Common Files\Pd (%ProgramFiles% is where your programs are installed)

Other versions of Pd

This was included in Pd-vanilla in version 0.43, and in Pd-extended in version 0.41.

Discussion

These choices of directories has been discussed quite a bit. If you are interested in reading about how they were chosen, then read the:

http://lists.puredata.info/pipermail/pd-list/2008-06/063086.html

http://lists.puredata.info/pipermail/pd-list/2008-07/063769.html

http://lists.puredata.info/pipermail/pd-dev/2009-04/013302.html

Discussion (Linux specific)

Here are some references to discussion about storing architecture-dependent binaries somewhere in $HOME.

http://lists.freedesktop.org/archives/xdg/2009-June/010716.html (nicknaming architecture/OS)

http://lists.freedesktop.org/archives/xdg/2008-November/010010.html (.local/share, .local/lib, $HOME/lib, or what?)

http://lists.freedesktop.org/archives/xdg/2007-November/009029.html (All binaries should go to either $prefix/bin or $prefix/lib{,64} - these are the only directories guaranteed to be mounted with exec rights and not shared across different architectures (as is sometimes done for /$prefix/share))

http://lists.freedesktop.org/archives/xdg/2007-November/009030.html (If the plugins are dlopened objects, my opinion is that they are right in a subdir of $prefix/lib{,64})