<HTML>
<HEAD>
<TITLE>Pd Documentation 3</TITLE>
</HEAD>
<BODY bgcolor="#ffffff">
<SMALL>
<div style="width:6.5in; margin-left:.5in">
<CENTER> <B>
Pd Documentation chapter 3: Getting Pd to run
</B> </CENTER>
<BR>
<A href=index.htm#s3> back to table of contents </A>
<BR><BR>
Pd runs under Irix, Windows, and Linux.
How to get Pd up and running depends on your operating system,
but the overall strategy is the same.
You must first get and install it, and
then untangle whatever problems arise in handling audio and MIDI input
and output, and finally get Pd to meet its real-time obligations reliably.
In case of trouble also consult the Pd mailing list archive on
<A href="http://iem.kug.ac.at/mailinglists/pd-list/">
http://iem.kug.ac.at/mailinglists/pd-list/</A>
, which often has late-breaking news about configuration problems and solutions.
<P>
You may be interested in getting only audio output or audio input, or
you may need both to run simultaneously. By default, Pd will try to run
both, but if you don't need either input or output, you may find that Pd
runs more reliably, or at least more efficiently, with the unused direction
turned off. This is controlled by Pd's command line flags.
<P>
Depending on your application you will have a more or less stringent latency
requirement. Ideally, when any input (audio, MIDI, keyboard, network) is
available, the outputs (in particular the audio output) should react instantly.
In real life, it is necessary to buffer the audio inputs and outputs, trying
always to keep some number of milliseconds ahead of real time to prepare for the
inevitable occasions where the CPU runs off to service some different task
from Pd. How small this latency can be chosen depends on your OS and your
audio driver.
<P>
To test audio and MIDI, start Pd and select "test Audio and MIDI" from the
"help" menu.
<P> TIP: If Pd starts up but you get distortion or glitches in the audio
output, this could be either because the "audio I/O buffer" isn't big enough,
or else because the CPU load of the patch you're running is too great for the
machine you have, or else because the ADC and DAC are out of sync or even at
different sample rates. To test for the first possibility, try increasing the
"-audiobuf" parameter in the command line (but see also under your OS below.)
For the second, start up your favorite performance monitor program; and for the
third, try starting Pd up with ADCs disabled.
<P> Here are instructions for getting and installing Pd for the four
operating systems it runs on: IRIX, MS Windows, Linux, and Max OSX.
<H4> <A name=s1.1> 3.1. IRIX (SGI machines) </A> </H4>
<P> Download Pd, which will be a "tar.Z" file. You can unpack this by
typing "zcat [name].tar.Z | tar xf -" to a shell. This creates a directory
named "pd".
<P>
Starting with release 0.25, Pd should come in "n32" and "o32" versions.
"o32" is the default and will run on IRIX 5.x and up. "n32" runs faster,
but only on 6.x and up. Also, "externs" have to be updated for n32. The
"pd" executable (bin/pd in the distribution) is a symbolic link to either
"pd-o32" or "pd-n32."
<P> NOTE: "externs" appear to be broken in the N32 version... I'm not sure
how long this has been true. If you want to use external objects, you have
to use the O32 version.
<P>
Please note that the path to the Pd executable program can't contain
space characters; don't put it in a directory named "Program Files"
for example.
<P>
If for example you put Pd in ~, the executable program
will be ~/pd/bin/pd. The program looks at its command line to
figure out where it is, so it's best to invoke Pd by its full pathname.
You should always invoke Pd from a Unix shell because many important
messages appear on the standard error.
<P>
The simplest way to invoke Pd is to
make an alias in your ".cshrc" file (assuming you use the "c" shell) such as:
<PRE>
alias pd ~/pd/bin/pd
</PRE>
(assuming your Pd distribution landed in ~, for example).
<P>
Pd will open the "default" audio input and output devices, without regard
for whether they are in sync or not. This will be bad if they aren't; use
the "-noadc" or "-nodac" flag to disable either the input or output. Pd is
supposed to handle up to 8 channels of audio in and/or out. (But at least
one user had to recompile Pd on his Onyx to get 8 channels working.)
<P>
As to MIDI, Pd simply attempts to open all available MIDI devices for input and
output, which is probably very bad on anything more recent than my Indy. If
any MIDI ports fail to open either for input or output, all MIDI is disabled.
<P> Pd has not been fixed to request real-time priority from Irix; it will
compete with all other processes on your machine for CPU time.
<H5> Audio and MIDI in IRIX </H5>
<P>
Pd takes command line arguments to set the number of input and output channels
and the sample rate. These don't affect the SGI's audio settings, which you
have to set separately using the "audio panel." Pd does detect the audio
sample rate if you don't specify one on the command line.
<P>
On SGI machines, you have to work to get MIDI running. Before you start Pd, verify
that least one MIDI port is configured open. Pd opens the FIRST MIDI port
that's open. You might want to get rid of the "software" MIDI port if you're
running 6.x. On Indys, the usual practice is to open serial port number 2
because some systems configure port 1 as "console" by default. You can use the
GUI if you want, or else just type
<PRE>
startmidi -d /dev/ttyd2
</PRE>
to get port 2 speaking MIDI, and
<PRE>
stopmidi
</PRE>
to stop it. You can test whether MIDI is configured by typing,
<PRE>
ps -dafe | grep midi
</PRE>
and looking for "startmidi" processes.
<P>
It's a good idea to connect your serial port to your MIDI interface before
typing the "startmidi" command, not afterward, at least in 5.x. We use the
Opcode Studio 3 interface but in principle any Mac-compatible one should work.
<P>
The O2 apparently has RS232 ports, not RS422. I think SGI's web site says
something about how to deal with this.
<H4> <A name=s1.2> 3.2. Microsoft Windows </A> </H4>
<P> Pd is compiled under NT, but shoould work under any version of Windows
since 95. Pd will appear as a "zip" file. Unzip this, creating a directory
such as \pd. (You can put it wherever you like but the path should have no
spaces in it; so "Program Files" would be a bad place.)
<P>
If for example you put Pd in C:\pd, the executable program will be
C:\pd\bin\pd. You can simply adjust your path to include C:\pd\bin and just
invoke "pd" in a command prompt window. You can also make a "command prompt"
shortcut to start Pd.
<P> Pd requires "TCP/IP networking" to be turned on. This doesn't mean you
have to be on a real network, but simply that Pd actually consists of two
programs that make a "network link" to intercommunicate.
<H5> The vanishing window </H5>
<P> Pd is a "command line" program. Most error and diagnostic
messages from Pd appear on the command prompt window Pd runs from.
<P> If you start Pd from the "run" menu or as a shortcut, and if there's
a problem with run-time flags (see the Pd command line below), Pd will
print an error and exit. You won't see this error unless you arrange for the
"command prompt" or "msdos" window to stay open after Pd exits. One way
to do this is to make a "batch" file ("run.bat", say) containing the Pd
command line.
<H5> Audio in Microsoft Windows </H5>
<P>
You can ask for a list of audio and MIDI devices by typing
"pd -listdev"; you can then specify which audio and MIDI device to use.
Type "pd -help" (or make any mistake) to get the syntax for specifying
which device to use.
<P>
Most PC sound cards seem to have MIDI built in; you don't seem to have to
do anything special to get Pd to send and receive MIDI. You can list and
choose MIDI devices in the same way as audio.
<P>
MIDI timing is very poor if you are using simultaneous audio input and output;
if you suppress either audio input or output things will improve somewhat under
NT; you can apparently get the jitter down to ~40 msec. On W95 performance is
simply terrible. W98, with either audio input or output suppressed, offers
fairly good MIDI timing (~5 msec jitter) but crashes occasionally.
<P> Some NT and W98 drivers greet you with a constant trail of "resyncing
audio" messages. Sometimes you can fix this by invoking Pd with the "-noresync"
flag.
<H5> ASIO </H5>
<P> As of version 0.35 Pd supports ASIO. Invoke Pd as "pd -asio" and, if
needed, specify "-sounddev" (etc.) flags to specify which device (see
"the Pd command line" below.) You can also specify a "-blocksize" different
from the default (256 samples) and "-audiobuf" in milliseconds. Pd will
round this down to a power of two buffers, each of "-blocksize" in sample
frames.
<P> Using an RME Hammerfall, and specifying "-audiobuf 5 -blocksize 32" I
was able to get about 7 milliseconds of throughput delay (as measured by
the latency-measurement patch in 7.stuff/tools.) As always, you can specify
"-channels" to any even number up to the maximum (32, I think) or can specify
channel count separately for input and output (-inchannels and -outchannels).
<H5> The special joys of Windows 95 </H5>
<P>
On Windows 95 you can expect a hard time. Every user who tries it seems to
encounter a new problem. The best way to run Pd is to get into the "MSDOS
Prompt" program and type \pb\bin\pd to it (or whatever the path ends up being.)
You can probably put pd's "bin" directory in your path so that you just type
"pd" to the prompt.
<P>
You don't want to run Pd from the "run" menu because if it fails to start up
the window holding the error message will disappear instantly. Ditto for
clicking on "batch files" or on the Pd executable itself.
<P>
The most common reason Pd might fail to start up in W95 is not having
"networking" turned on. Pd is actually two programs that establish an IP
interconnection. Beware that this sometimes fools Windows into calling your
ISP for no reason.
<P>
It is often necessary to specify a huge audio buffer to get steady audio
output in W95; see the command line arguments below.
<H4> <A name=s1.3> 3.3. Linux </A> </H4>
<P> What to do depends on which flavor of Linux you are running (e.g., Debian
or Red Hat). The instructions here should work for Pd 0.33 and up regardless of
your situation, but if you have any trouble just mail msp@ucsd.edu and I'll try
to figure out what's wrong and update the instructions accordingly.
<P> Before you start, you might want to check that you have the resources Pd
needs. The main things you need are the C compiler, X windows (including
the X development package for Pd to link against) and TK. If you're running
Redhat or Mandrake 7.x or up, I think these are all present by default.
The RedHat X client developer "RPM" package is called XFree86-devel.
<P> You don't absolutely have to have the X server package running; you can run
Pd on the microprocessor in your refrigerator as long as it can connect to an X
server on another machine.
<P> If you're running RedHat you might want to use RPM to install Pd. For
other linux distributions, download the "tar.gz" version and compile it.
<H5> Getting Pd as an RPM </H5>
<P> Download Pd, perhaps from
<a href="http://www.crca.ucsd.edu/~msp/software.html">
http://www.crca.ucsd.edu/~msp/software.html</A> ,
to a file such as "pd-0.33-0.i386.rpm".
Open a "shell" window, cd to
the directory containing the file, and type the command,
<PRE>
rpm -i pd-0.33-0.i386.rpm
</PRE>
<P> (substituting the real file name.) Then you should be able to type "pd"
to a shell and watch the Pd main window appear.
<H5> Getting Pd as a .tar.gz </H5>
<P>
Download Pd, perhaps from
<a href="http://www.crca.ucsd.edu/~msp/software.html">
http://www.crca.ucsd.edu/~msp/software.html</A> ,
to file such as "pd-linux-033.tar.gz". Open a "shell"
window, cd to
the directory containing the file, and type the command,
<PRE>
zcat pd-linux-033.tar.gz | tar xf -
</PRE>
which creates a directory named "pd". I do this from my home directory.
Next, compile it. "CD" to pd and read the INSTALL.txt, or else just cd
to "pd/src" and type
<BR> ./configure
<BR> make depend
<BR> make
<P> You can pass flags to "configure" to customize your compilation:
<PRE>
To enable ALSA 0.9x (the latest one), add "--enable-alsa".
To enable the older ALSA 0.5x, add "--enable-old-alsa".
To enable Ritsch's RME 9652 driver, add --enable-rme".
To put Pd in /usr/bin instead of /usr/local/bin, add "--prefix=/bin".
</PRE>
<P> After "make", just type "~/pd/bin/pd" to run pd.
<P> Alternatively, as superuser, you can run "make install" after "make depend"
and then anyone on your system can just type "pd" to run it.
<H5> TK support trouble </H5>
Some people have reported a problem with Pd findind the shared libraries,
"libtcl.so" and "libtk.so". I don't know what causes this, but apparently you
can fix it, as root, by linking /usr/lib/libtcl8.3.so to /usr/lib/libtcl.so and
similarly for tk:
<PRE>
# cd /usr/lib
# ln -s libtk8.3.so libtk.so
# ln -s libtcl8.3.so libtcl.so
</PRE>
<H5> Testing audio and MIDI. </H5>
<P>
Next try audio. We want to know whether audio output works, whether audio
input works, and whether they work simultaneously. First run "aumix" to
see audio input and output gains and which device is "recording".
Then test audio output by running
<PRE>
pd -noadc
</PRE>
and selecting "test audio and MIDI" from the "help" menu. You should see a
patch. Turn on the test tone and listen. Do the usual where's-the-signal
business.
<P>
Then quit Pd and test audio input via
<PRE>
pd -nodac
</PRE>
Re-open the test patch and hit "meter"; look at the levels. 100 dB is a
hard clip; arrange gains so that the input signal tops out around 80 or 90,
but no higher.
<P> Now see if your audio driver can do full duplex by typing "pd" with no
flags. If you see error messages involving /dev/dsp or /dev/dsp2, you're
probably not able to run audio in and out at the same time. If on the other
hand there's no complaint, and if the audio test patch does what you want, you
might wish to experiment with the "-audiobuffer" flag to see what values of
audio latency your audio system can handle.
<H4> Audio hardware in Linux </H4>
<P>
Be forewarned: installing and testing audio and MIDI drivers in Linux can take
days or weeks. There apears to be no single place where you can get detailed
information on Linux audio. In addition to the information here, you should
see what's posted on Guenter's page,
<a href="http://gige.epy.co.at/">
http://gige.epy.co.at/</A> .
<P>
Depending on your hardware and software, you might or might not be able to
run "full duplex," i.e., use audio input and output at the same time. For
many applications it's important to be able to do this, but if by any chance
you don't need simultaneous input and output you will have much less trouble
than if you do.
<P>
There are two widely-used driver sets, called "OSS" and "ALSA". OSS is
included in the standard Linux kernels since version 2.2. However, for some
audio cards you can find newer versions than are included in the kernel
releases. You can get ALSA from
<a href="http://www.alsa-project.org/">
http://www.alsa-project.org/</A> .
<P>
(There is also a commercial version of the OSS drivers which costs $30 (slightly
more for certain audio cards.) Hit
<a href="http://www.opensound.com/">
http://www.opensound.com/</A> .
These might be easier to use than the free OSS drivers, but I've never tried
them.)
<P> ALSA is able to emulate OSS, so that you can usually run Pd using the
default "OSS" settings even if it's actually ALSA that's running.
<H5> Installing and configuring FREE OSS </H5>
<P>
OSS is really a collection of loadable device drivers. The commands
for loading and unloading the drivers are "insmod" and "rmmod".
You can see if the audio drivers are
running using "lsmod" (as root.) If you see something like:
<PRE>
Module Pages Used by
eepro100 3 1 (autoclean)
opl3 3 0
opl3sa2 1 0
ad1848 4 [opl3sa2] 0
mpu401 5 [opl3sa2] 0
sound 15 [opl3 opl3sa2 ad1848 mpu401] 0
soundcore 1 [sound] 6
soundlow 1 [sound] 0
aic7xxx 23 2
</PRE>
then OSS is running, and if all you see is:
<PRE>
eepro100 3 1 (autoclean)
aic7xxx 23 2
</PRE>
then it isn't. You can turn OSS off by running "rmmod" repeatedly, starting
with "opl3" (or whatever) so as not to remove any module before you remove
all the modules that depend on it. In the above listing, "opl3*" is device
dependent and you might see different names.
<P>
The file, "/etc/modules.conf" apparently controls which sound drivers are
started at boot time. The sndconfig program updates this file but you can
also change things manually, for instance to switch between two different sound
cards. In Redhat 6.x and earlier, the file is named "conf.modules."
<P> Here is a modules.conf file for OSS:
<PRE>
alias eth0 e100
alias parport_lowlevel parport_pc
alias char-major-81 bttv
alias usb-controller usb-uhci
alias sound-slot-0 i810_audio
alias sound-slot-1 es1371
</PRE>
Here the two sound cards are the (motherboard resident) i810 driver and an
ensoniq es1371.
<P> In RedHat at least, the "sndconfig" program tries to automatically search
for your soundcard. Unfortunlately it only finds the "first" one which is
often not the one you want to use!
<P> Under OSS, programs can stream sound using either
"block" or "stream" mode. Stream mode is the more modern and better of the
two, but the majority of drivers, even for new sound cards, only
support "block." Pd makes "block" the default.
<H5> ALSA (Advanced Linux Sound Architecture) </H5>
<P> ALSA is newer, hence less stable and harder to use, than OSS.
Alsa comes in a "finished" version (0.5.x) and a
different, redesigned, "beta" version, 0.9. Installing ALSA can be tricky
and/or confusing.
<P> As of version 0.33 Pd works with either 0.5.x or 0.9.x versions.
The RPM version of Pd is compiled for 0.9.x. If you're starting from the
".tar.gz" version, you have to "./configure --enable-alsa" to get it; see
the "INSTALL.txt" file in the installation.
<P> By default, Pd uses OSS. If you are running ALSA, Pd will use ALSA's OSS
emulation. To make Pd use ALSA "natively", i.e., the way ALSA is designed
to be used, include the "-alsa" flag in the command line.
<P> In ALSA, you can specify which sound card to use using the "-alsadev"
flag. So, for instance, "-alsadev 3" means your third card, counting from
one. You can also specify it the ALSA way: "-alsadev hw:3,0".
<H5> Which sound card? </H5>
<P>
Here's a rundown on my experiences with sound cards so far. See
also the Pd mailing list archives.
<H6> opl3sa </H6>
This is the old ISA "Yamaha" audio system. It comes on many Dell machines and
seems to offer reasonable consumer quality audio, at least under NT. I
believe the current version of OSS can get full duplex operation out of an
OPL3sa audio system.
This is an ISA ("plug and play" device and you have to deal with I/O
addresses and all that.
<H6> cs4232 </H6>
The 1999 vintage dual-processor Dell machines have "cs4232" audio, which I
couldn't get working.
<H6> es1370 (old Creative PCI128s; Ensoniq AudioPCI) </H6>
<P>
The audio inputs and outputs on my PCI128 aren't clearly labelled and various
documents give them inconsistent names. On my card there are 4 stereo
mini jacks and a joystick port, in this order:
<PRE>
joystick black green red blue
bidirectional line-out mic-in line-in
</PRE>
<P> It used to be possilbe to get quadraphonic audio in and out
of this card, but I haven't tried this in years.
<H6> Creative SBLive </H6>
This seems to work fine either with ALSA or OSS as of Pd version 0.35; earlier
versions of Pd didn't see MIDI input under OSS (the driver's fault, not Pd's,
but I figured out a workaround.)
<H6> Sonorus Stud I/O </H6>
This $1000 card is supposed to do multichannel digital I/O
in Linux, via a beta version of a commercial OSS driver ($40).
I don't know if anyone has used it with Pd.
<H6> RME 9652 (Hammerfall) </H6>
<P> This is the best sound card out there; it costs around $500 and has 3 ADAT
I/O ports and one SPDIF. There is a "baby hammerfall" also, which I think is
the "9632." DO NOT CONFUSE THE 9652/9632 WITH OTHER RME BOARDS WHICH MIGHT
NOT WORK WITH PD.
<P> Guenter Geiger has an OSS driver for Hammerfall for 2.4 kernels (such as
RedHat 7.1 and up). You have to download and compile it:
<A HREF=http://gige.xdv.org/pages/rme>
http://gige.xdv.org/pages/rme </A>.
<P> You must then run Pd using the "-32bit' flag, because this uses a
non-standard extension of OSS to 32 bit samples.
<P> There's an older driver by Winfried Ritsch, invoked using the "-rme"
flag to Pd. This only works on 2.2 kernels, and you probably shouldn't
try it. It will probably be discontinued after Pd version 0.35.
<P> Hammerfalls now have an ALSA driver; from what I hear
it won't work yet with Pd. I was unable to install the ALSA driver on the
two machines I tried ("no such device").
<H6> MIDIMAN </H6>
Midiman sells devices with between 4 and 12 analog channels in and out, for
which there are ALSA drivers. It seems to work fine with the old ALSA driver
(0.5). I'm running mine in Alsa 0.9 beta 10. The driver name is "ice1712".
<P> Alsa provides an "envy24control" program (in "utils". You should run
this and check that your ice1712's sync source is internal if you have no
SPDIF input, or "SPDIF" if you do. I think the default is now "internal"
but don't take it for granted...
<H6> i810/i815 </H6>
In RedHat 7.0, motherboards with native i810 audio systems don't work in
full duplex (they crash linux). Either run Pd -noadc or else (better) install
ALSA.
<H6> Yamaha YMF724 </H6>
The OSS driver for this card appears not to support MIDI. I haven't
tried with ALSA.
<H6> ES1371 </H6>
In OSS, audio and MIDI seem both to work fine with this chipset.
<H4> <A name=s1.4> 3.4. Macintosh OSX </A> </H4>
Pd version 0.35 supports Macintosh OSX, although there are still various
problems. You can either download Pd with Mac OSX binaries, or just download
the sources and compile it yourself.
<H5> To install the binary OSX release: </H5>
<P> First download and install TK for OSX
(http://sourceforge.net/projects/tcl/). Get a recent one compiled for
OSX, by chasing through "Mac OS X Tk Snapshots." I got
version 8.4a4-2, in a file named "MacOSXTk8.4a4-2.tar.gz ". Unpacking this
yields three directories: ./Applications/Wish Shell.app,
./Library/Frameworks/Tcl.framework,
and ./Library/Frameworks/Tk.framework. These must be moved, either to:
<pre>
~/Applications/Wish Shell.app
~/Library/Frameworks/Tcl.framework
~/Library/Frameworks/Tk.framework
</pre>
or, if you wish to make them available to other users (or make it possible to
recompile Pd), in /Applications and /Library instead.
<P> Then download and unpack the Pd binary distribution for OS X. This will
create a directory with a name like ~/Desktop/pd-0.35-test22. You can move
this elsewhere if you wish (to ~/pd, for example). To a shell window, type
either "~/Desktop/pd-0.35-test22/bin/pd" or, if you moved it as suggested,
"~/pd/bin/pd" . If you wish you can put the line,
<pre>
alias pd ~/pd/bin/pd
</pre>
in the file, ~/.tcshrc, so that you can later just type "pd" to a shell. (The
shell only reads the ~/.tcshrc file onstartup, so this won't take effect in
any existing shells unless you specially type
<pre>
source ~/.tcshrc
</pre>
to them.)
<P> In some cases you have to explicitly give "-soundindev" and "-soundoutdev"
flags for Pd to open audio correctly; "pd -listdev" should show you the
correct device numbers.
<P> To get MIDI working, you have to do the Mac OSX magic to get a USB
MIDI interface installed. I've seen this done with Midisport devices and
I think you just download the OSX driver and follow directions.
<P> On the machine I tried, it was necessary to type,
<pre>
pd -midiindev 1 -midioutdev 2
</pre>
to get MIDI working. At the moment, using a midiman Midisport 2x2, I'm getting
several lines of debugging printout for each incoming MIDI message; it seems to
be the driver printing it out. I don't know how to turn this off.
<P> To get Pd running at high priority, so that you'll get fewer skips in the
audio input and output, you must "renice" it. The easiest way to do this is
to make it SETUID and use the "-rt" flag. To do this, become root (you might
have to add a root account to do this) and type:
<pre>
chown root ~ferguson/pd/bin/pd
chmod 4755 ~ferguson/pd/bin/pd
</pre>
(assuming your username is "ferguson").
<H5> To compile your own Pd in OSX: </H5>
Whether you've downloaded the source or the OSX binary distribution you can
always Pd for yourself, whether to make your own improvements, or possibly
so that you can get the newest version before it shows up compiled
for Mac OS X.
<P> To be able to compile Pd, you must have installed Tcl/Tk
specifically in
/Applications/Wish Shell.app
and /Library/Frameworks/Tk.framework and /Library/Frameworks/Tcl.framework.
You must also get the "h" files from XFree86 and put them in
/usr/X11R6/include. You can download just the H files from:
<pre>
http://www.crca.ucsd.edu/~msp/x.tgz
</pre>
(the individual files seem to have adequate copyright notices so that
I can just redistribute them.)
Then, just as for linux, just unload pd-whatever.tar.gz into a directory
such as ~/pd-0.35-test17 , cd to pd-0.35-test17/src, type "./configure"
and "make".
then type ~/pd-0.35-test17/bin/pd to a shell and enjoy!
<H4> <A name=s3> 3.5. graphics rendering using GEM </A> </H4>
<P>
GEM, originally by Mark Danks but now supported by Iohannes Zmoelnig, is essentially an extension of Pd that allows you to do OpenGL programming
using a suite of "GEM objects" roughly parallel to the tilde objects built
into Pd for audio. Find out more from
<a href="http://iem.kug.ac.at/~zmoelnig/index.html"> Johannes's page</a>.
<H4> <A name=s4> 3.6. The Pd command line </A> </H4>
Pd is a "command line" program. The best way to run it is from your
"terminal emulator," "shell," or "MSDOS prompt." The command line is:
<PRE>
pd [options] [patches to open]
</PRE>
although you may have to specify a path so your command interpreter can find
Pd (OS dependent.) Possible options include:
<PRE>
audio configuration flags:
-r <n> -- specify sample rate
-inchannels ... -- number of audio in channels (by device, like "2" or "16,8")
-outchannels ... -- number of audio out channels (by device)
-channels ... -- specify both input and output channels
-audiobuf <n> -- specify size of audio buffer in msec
-blocksize <n> -- specify audio I/O block size in sample frames
-sleepgrain <n> -- specify number of milliseconds to sleep when idle
-nodac -- suppress audio output
-noadc -- suppress audio input
-noaudio -- suppress audio input and output (-nosound is synonym)
-listdev -- list audio and MIDI devices
-audioindev ... -- sound in device list; e.g., "2,1" for second and first
-audiooutdev ... -- sound out device list, same as above
-audiodev ... -- specify both -audioindev and -audiooutdev together
(linux specific audio:)
-frags <n> -- specify number of audio fragments (defeats audiobuf)
-fragsize <n> -- specify log of fragment size ('blocksize' is better...)
-stream -- use stream mode audio (e.g., for es1370 audio cards)
-alsa -- use ALSA audio drivers
-alsadev <n> -- ALSA device # (counting from 1) or name: default hw:0,0
MIDI configuration flags:
-midiindev ... -- midi in device list; e.g., "1,3" for first and third
-midioutdev ... -- midi out device list, same format
-mididev ... -- specify -midioutdev and -midiindev together
-nomidiin -- suppress MIDI input
-nomidiout -- suppress MIDI output
-nomidi -- suppress MIDI input and output
general flags:
-path <path> -- add to file search path
-open <file> -- open file(s) on startup
-lib <file> -- load object library(s)
-font <n> -- specify default font size in points
-verbose -- extra printout on startup and when searching for files
-d <n> -- specify debug level
-noloadbang -- suppress all loadbangs
-nogui -- suppress starting the GUI
-guicmd "cmd..." -- substitute another GUI program (e.g., rsh)
-send "msg..." -- send a message at startup (after patches are loaded)
-rt or -realtime -- use real-time priority (needs root privilege)
-frags <n> -- specify number of audio fragments (defeats audiobuf)
-fragsize <n> -- specify log of fragment size ('blocksize' is better...)
-blocksize <n> -- specify audio I/O block size in sample frames
-stream -- use stream mode audio (e.g., for es1370 audio cards)
-alsa -- use ALSA audio drivers
-alsadev <n> -- ALSA device # (counting from 1) or name: default hw:0,0
(MS Windows specific audio:)
-resync -- resynchronize audio (default if more than 2 channels)
-noresync -- never resynchronize audio I/O (default for stereo)
-asio -- use ASIO audio driver (and not the 'MMIO' default)
MIDI configuration flags:
-midiindev ... -- midi in device list; e.g., "1,3" for first and third
-midioutdev ... -- midi out device list, same format
-nomidiin -- suppress MIDI input
-nomidiout -- suppress MIDI output
-nomidi -- suppress MIDI input and output
general flags:
-path <path> -- add to file search path
-open <file> -- open file(s) on startup
-lib <file> -- load object library(s)
-font <n> -- specify default font size in points
-verbose -- extra printout on startup and when searching for files
-d <n> -- specify debug level
-noloadbang -- suppress all loadbangs
-nogui -- suppress starting the GUI
-guicmd "cmd..." -- substitute another GUI program (e.g., rsh)
-send "msg..." -- send a message at startup (after patches are loaded)
-rt or -realtime -- use real-time priority (needs root privilege)
</PRE>
Here are some details on some of the audio and MIDI options (but see also the
next section on file management.)
<H5> sample rate </H5>
The sample rate controls Pd's logical sample rate which need not be that of
the audio input and output devices. If Pd's sample rate is wrong, time will
flow at the wrong rate and synthetic sounds will be transposed. If the output
and input devices are running at different rates, Pd will constantly drop frames
to re-sync them, which will sound bad. You can disable input or output if this
is a problem.
<H5> audio buffer size </H5>
You can specify an audio buffer size in milliseconds, typically between 10 and
300, depending on how responsive your OS and drivers are. If this is set too
low there will be audio I/O errors ("data late"). The higher the value is,
on the other hand, the more throughput delay you will hear from the audio
and/or control inputs (MIDI, GUI) and the audio coming out.
<P> In Linux and Windows, you can also specify the audio block size in sample
frames (but in Windows, this is only effective when using ASIO).
<H5> MIDI devices </H5>
<P> You can specify multiple MIDI input and output devices. For example,
"pd -midiindev 3 -midioutdev 4,2" asks for the third MIDI input device and the
fourth and second MIDI output device. The "channel message" midi objects in Pd
such as notein or pgmout will take channels 1-16 to mean the first open MIDI
port, 17-32 the second one, and so on. The midiin, sysexin, midiout objects
give you a separate inlet to specify which of the open MIDI port numbers
you want.
<P> In Linux, if you
ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00
(or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device
number 0 is the "MIDI mapper", which is the default MIDI device you selected
from the control panel; counting from one, the device numbers are card
numbers as listed by "pd -listdev."
<H4> <A name=s5> 3.7. dealing with files </A> </H4>
Pd has a search path feature; you specify the path on the command line
using the "-path" option. Paths may contain any number of files. If you
specify several files in a single "-path" option they're separated by colons
in unix or semicolons in NT. When Pd searches for an abstraction or an
"extern" it uses the path to try to find the necessary file. The "read"
messages to qlists and arrays (aka tables) work the same way. NO SPACES MAY
APPEAR ANYWHERE IN THE SEARCH PATH, e.g., "c:\my nonsense\goobers" won't
work.
<P> Filenames in Pd are always separated by (unix-style) forward slashes, even
if you're on Windows (which uses backslashes). This is so that patches can be
ported more easily between operating systems. On the other hand, if you
specify a filename on the command line (as in "pd -path c:\pdlib") the file
separator should agree with the operating system. <BR>
<P> If a filename in a patch has any "/" characters in it, the "path" is not
used; thus, "../sounds/sample1.wav" causes Pd only to look relative to the
directory containing the patch. (You may also invoke externs that way.)
<P> As of version 0.35, there may be spaces in the path to Pd itself; also,
the "openpanel" and "savepanel" objects can handle spaces. But still not
the search path.
</BODY>
</HTML>