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:
Hey hey,
I recently tried to get PD to work on my Arch system, using the
"official" pacman package (version 0.47.1).
Thanks to Iohannes, I was made aware of the -nogui option, so I ran a
patch like this:
pd -nogui -jack -alsamidi patch.pd
The patch is also from last year. This results in a lot of errors, like
these:
prvu~
error: ... couldn't create
verbose(4): ... you might be able to track this down from the Find menu.
sin~
error: ... couldn't create
average~ 1000
error: ... couldn't create
...
and similar. Using the jack option PD also segfaults. Without using
that, it can't find an audio device and just talks to its watchdog.
JACK is also system supplied and works with everything else. It's run
under the same user. Even giving the option to set the samplerate
doesn't change anything.
Any ideas, what I could try? Perhaps some special system variable
setting a path?
Thanks and goodnight,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
