Personal tools
You are here: Home documentation FAQ for Pd
Document Actions

FAQ for Pd

View entire FAQ in full Up to Table of Contents
Frequently Asked Questions regarding Pd (now with answers) If you have something to contribute to this page, log into and you will have edit access.

Tips and Tricks

How do I accumulate (or sum) audio outlets of several modules without so many connections?

Use [throw~] and [catch~].

See the help patches for those objects.

How do I run Pd from the command line?

Starting Pd on the command line works differently on each platform (GNU/Linux, Mac OS X, and Windows).

Usually you would use just pd on the command line. If Pd is installed in a non-standard location, like when building from source, you have to specify the full path to the binary. For example ~/trunk/pd/bin/pd. Alternatively you can first cd to Pd's bin directory, and then start ./pd. For example, cd ~/trunk/pd/bin/ && ./pd
Mac OS X
Since Pd on Mac OS X has a different start-up procedure than the other platforms, start the GUI process: /Applications/ or /Applications/ To run the pd process first, you have to have the Tcl/Tk's installed on your computer somewhere findable, like /Applications. Then run: /Applications/
If you are using the Windows cmd.exe shell, use Windows paths: C:\Program Files\pd\bin\ You could also run C:\Program Files\pd\bin\ from Start -> Run... and it will launch its own cmd.exe.
When using a Cygwin shell, you need to use UNIX-style paths with Cygwin's special directories for Windows drive letters: /cygdrive/c/Program\ Files/pd/bin/
When using a MinGW MSYS shell, you need to use UNIX-style paths with MSYS's special directories for Windows drive letters: /c/Program\ Files/pd/bin/

How do I get an acceptable performance and latency on the MS Windows platform?

I've Installed Pure Data (or Pd-extended) on Windows and I have to set the buffer (delay) to more than 100ms to avoid audio drop outs (crackling). What can I do to achieve a proper latency in Pd on Microsoft Windows?

Make sure your Windows system is set up for Audio. Make sure the overall system performance is OK, install updated ASIO drivers for your soundcard or the "ASIO4All Drivers": when no ASIO is available from the manufacturer. There is also an "ASIO driver for WDM kernel-streaming compliant soundcards":

Read Native Instrument's "Windows 7 Tuning Tips for Audio Processing":

Also read RME's "Tuning Tips for Low Latency Operation": (slightly older, possibly outdated)

USB and persitency

If you have the problem that you can only plug in your external sound card to one specific USB port you might want to make the COM port assignment of the system permanent to this device. Here is How: goto control panel -> device manager -> com ports -> properties -> port settings -> advanced -> comport number there you can permanently set the comport number for that device.

How can I set permissions to read HID devices on GNU/Linux?

The Pd-extended [hid] object allows you to access Human Interface Devices such as mice, keyboards, and joysticks. However, in most Linux distributions, these devices are setup to where they cannot be read directly by Pd unless you run it as root.

Running a non-system process as root is considered a security risk, so an alternative is to change the permissions of the input devices so that pd can read them.

This guide has been tested on Ubuntu 9.10 Karmic. Please update and add an addendums for newer versions.

The fix is to write a udev rule opening permissions. Udev is a system daemon that creates the device tree in /dev as devices are added and removed based on a set of rules.

Following the Debian udev rules naming policy, create our rule for pd in /etc/udev/rules.d/85-pure-data.rules:

sudo mkdir -p /etc/udev/rules.d
sudo gedit /etc/udev/rules.d/85-pure-data.rules

Note: This is the Debian/Ubuntu location. Check your distribution for where it puts udev rules.

Now add the following rules to /etc/udev/rules.d/85-pure-data.rules:

#	pure data udev rules
#	Put me in "/etc/udev/rules.d", I am named based on the debian udev rules format
#	"add" actions are device insertions and device attributes are used to match the device
#	"remove" actions are matched using ENV variables since the SYSFS node for the device is gone
#	and thus the attributes have been deleted
#	rules built using:
#	- udevadm info -a -p $(udevadm info -q path -n /dev/*device*) : attributes
#	- sudo udevadm monitor --env /dev/*device* : events and env vars
#	Documentation is your friend:

#	input devices
SUBSYSTEM=="input", MODE="666"

Note: each udev rule must on a single line. Use only spaces, no tabs. Lines that start with `#` are comments.

This rule sets the permissions to 666 for input devices. Reboot your machine and the HID object should now be able to open them.

More Security

Setting input devices to 666 also opens the chance for someone to read your keyboard and mouse input. If you feel this is a security risk, try swapping MODE="666" with the following:

GROUP="input", MODE="660"
Then create an "input" group and add yourself to it:
sudo groupadd -f input
sudo gpasswd -a YOURUSERNAME input

This will add any input devices to the input group and only users you add to this this group can then read them. Reboot your machine for the rules to take effect.


Check the permissions of the input devices:
$ ls -al /dev/input/
total 0
drwxr-xr-x  3 root root     220 2010-06-10 22:00 .
drwxr-xr-x 16 root root    3640 2010-06-10 22:00 ..
drwxr-xr-x  2 root root     100 2010-06-10 22:00 by-path
crw-rw----  1 root input 13, 64 2010-06-10 22:00 event0
crw-rw----  1 root input 13, 65 2010-06-10 22:00 event1
crw-rw----  1 root input 13, 66 2010-06-10 22:00 event2
crw-rw----  1 root input 13, 67 2010-06-10 22:00 event3
crw-rw----  1 root input 13, 68 2010-06-10 22:00 event4
crw-rw----  1 root input 13, 63 2010-06-10 22:00 mice
crw-rw----  1 root input 13, 32 2010-06-10 22:00 mouse0
crw-rw----  1 root input 13, 33 2010-06-10 22:00 mouse1

Here I used the more secure approach and you can see the event and mouse devices are marked rw for both users and groups.


If the rule dosen't seem to work, you can run a udev test to see if it's being read and if there are any errors. Run the test using an input device:

sudo udevadm test /dev/input/event0

Check out the udev tutorial on how to create more detailed rules. It's actually pretty easy once you get the hang of it. Mainly, use the following command to get a list of attributes to match to your target device wehn you plug it in or remove it, then use them to create a new rule:

udevadm info -a -p $(udevadm info -q path -n /dev/*your device*)


How to add aliases for Pd scripting on Mac OSX

I wanted to be able to use some shell scripts using Pd I wrote in Linux on MacOSX, but the shell (Terminal) session does not know how to launch binaries from within Application Bundles.

On Linux, I can start pd by typing "pd" and hitting enter. On Mac OSX, I can start the Pd App by typing "open -a Pd-extended" ... but I'd rather be able access the pd binary within the bundle directly so one script can work in Linux and OSX.

The fix is pretty simple: Add an alias to the binaries within to your shell session.

Add the following to ~/.bash_profile:

# pd commandline
alias pd="/Applications/"
alias pdsend="/Applications/"
alias pdreceive="/Applications/"

Restart the shell session and now the "pd", "pdsend", and "pdreceive" commands should launch their respective targets.


~/.bash_profile is in your home directory, so any changes are only applied to your user account.

How can I run Pd with realtime priority on GNU/Linux?

In Linux, Pd can be run as a real time process by the root user, resulting in far fewer audio drop outs (clicks). Essentially, the operating system gives the Pd process more time to work without being interrupted by other programs.

Running non-system programs as root, however, is considered a security risk and is obviously not an option if the user doesn't have administrator access. Luckily, there is a system config file that accepts options for priority settings.

From theUbuntu Studio wiki.

NOTE: If you have installed JACK, editing /etc/security/limits.conf may not be necessary as newer versions of JACK add the same settings to this file: /etc/security/limits.d/audio.conf. Run the following command to check if the file exists. If you see something printed, you don't need to follow the steps below.

cat /etc/security/limits.d/audio.conf

All you need to do is give your "audio" group permissions to access the rtprio, and memlock limits. To do this, you just need to run these commands, which will add some lines to the file /etc/security/limits.conf and add you to the audio user group.:

sudo su -c `echo @audio - rtprio 99 >> /etc/security/limits.conf`
sudo su -c `echo @audio - memlock unlimited >> /etc/security/limits.conf`
sudo adduser username audio
Of course, replace username with your actual user name. Note: There is no audio group by default on versions of Ubuntu Intrepid or greater. You can create an audio group and add yourself to it by running these commands:
sudo addgroup audio
sudo addgroup username audio

Restart. Running pd using the real time flag, -rt, should now work and you should see something like "Realtime Priority Enabled" on the pd console. Run it like this (or add -rt to the startup options):

pd -rt
by Frank Barknecht last modified 2009-05-18 09:44 PM

Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser