Hi Jeanette, TL;DR: it seems a dependency problem. Try Pd-extended, a Pd distribution with many included libraries, or solving dependencies through Deken, a package manager for Pd. Pd-extended seems to have an Arch package: https://aur.archlinux.org/packages/pd-extended/ Longer version with explanation at the end. The patch you are trying to run probably requiring Pd-extended or at least a bunch of objects not included in Pd-vanilla. As said posssible strategies in this case are: 1. See if the patch just works installing Pd-extended which I see is included in arch: https://aur.archlinux.org/packages/pd-extended/ 2. Try and see if the objects generating errors like for example in your case prvu~, sin~ etc.) can be found through deken (this is a bit like dependency hunting when you need to compile a software from source). Problem is, I'm not sure deken can be used in gui-less mode 3. If the above fail, or still partially fail, start hunting the net for ways of getting the needed libraries. In some cases some objects can be trivially substituted in functionality, sometimes not. It depends a lot on the patch. Now for a slightly longer explanation of the Pd dependency scenario. In pd talk the version usually distributed (unless explicitly specified) is 'Pd vanilla' and only has the minimal set of objects. This is the official version developed and maintained by Miller. At a certain point a kind of alternative distribution labeled Pd-extended was made available and included lots of additional libraries. As far as I know Pd-extended is recently struggling keep in sync with more recent versions of Pd-vanilla. Also several other 'forks' have come into the scene competing with Pd-vanilla and offering similar extensions. Additionally, in recent versions of Pd-vanilla a kind of package manager was added - called Deken and cited above - which should make adding externals easier. One thing to keep in mind is that Pd objects are divided into two important categories: 1. Abstractions: these are actually constructed with other Pd objects, you could consider them as 'native'. They can be quite easily transported from one system to another as long as their dependencies are met. 2. Externals: these are binary objects, originally developed in C and then compiled according to the platform (on Linux the final product is an .so). They can be more challenging to get if you can't find them packaged. I'm not sure what your case is but if you can share your patch someone might look into the dependencies and try and create a package for you which is as 'self-contained' as possible. Hope this helps. Lorenzo. On 29/04/17 02:02, Jeanette C. wrote: