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."
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.
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.
The simplest way to invoke Pd is to make an alias in your ".cshrc" file (assuming you use the "c" shell) such as:
alias pd ~/pd/bin/pd(assuming your Pd distribution landed in ~, for example).
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 only supports stereo in the current version.
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.
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.
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.
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.
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.
It is often necessary to specify a huge audio buffer to get steady audio output in W95; see the command line arguments below.
What to do may depend on which flavor of Linux you are running (e.g., Debian or Red Hat) and on where you got Pd from (Miller or Guenter). The instructions here should work for Pd 0.26 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.
Before you start, you might want to check that you have the resources Pd needs. You can verify that you've got TK installed by typing, "wish" to a shell window. If you've got X windows running, I think it's almost certain that you also have TK. If you don't at least have the X client side up, you won't be able to run Pd. If you want to be able to compile your own Pd objects, you should also check that you have a C compiler by typing "gcc" to a command line. If you want to recompile Pd itself, you'll also need the X client developer package, which isn't installed by default on Red Hat at least; the package name is XFree86-devel.
Next try to get MIDI and audio working on your computer (see the next section). I don't know what software functions best as a test program; I use Pd but if you're reading this you might not be sure your copy of Pd is working yet.
Download Pd, perhaps from http://www.crca.ucsd.edu/~msp/software.html giving a file such as "pd-linux-026.tar.gz". Open a "shell" window, cd to the directory containing the file, and type the command,
zcat pd-linux-026.tar.gz | tar xf -which creates a directory named "pd". I use my home directory. Then if you use "bash" put the line,
alias pd=~/pd/bin/pdin the file ".bashrc" in your home directory. You can add options such as,
alias "pd=/home/me/pd/bin/pd -path /home/me/pdlib"to have Pd automatically search for files in /home/me/pdlib, for example. If you use the C shell (csh), you edit the .cshrc file and use the less painful syntax,
alias pd ~/pd/bin/pd -path ~/pdlibThen type ". .bashrc" or "source .cshrc" to make the change, and type "alias" to check that it happened. (you don't have to retype the "source" command for new shells; they run the "rc" file automatically.)
Next type,
pd -nosoundIf this works, you'll see the Pd window appear. Quit and go to the next paragraph. If this doesn't work, it could be because you're missing TK or even X windows, or more likely, that Pd isn't able to find its own files. This could either mean that you aren't invoking Pd by its full path name, or you're using a symbolic link, or that the files somehow got moved around.
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
pd -noadcand 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.
Then quit Pd and test audio input via
pd -nodacRe-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.
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.
Pd comes with multichannel audio support for IRIX, Windows, and Linux; on IRIX this should work without any trouble at all, but on the other two you have to be aware of many potential complications.
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.
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 yoru OS and your audio driver.
To test audio and MIDI, start Pd and select "test Audio and MIDI" from the "help" menu.
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.
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.
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
startmidi -d /dev/ttyd2to get port 2 speaking MIDI, and
stopmidito stop it. You can test whether MIDI is configured by typing,
ps -dafe | grep midiand looking for "startmidi" processes.
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.
The O2 apparently has RS232 ports, not RS422. I think SGI's web site says something about how to deal with this.
On Pcs, 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.
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.
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.
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.
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, http://gige.epy.co.at/ .
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.
There are two widely-used driver sets, called "OSS" and "ALSA". OSS ships with the Red Hat distribution, but the Red Hat documentation doesn't seem to point back to the original OSS distribution. You can get ALSA from http://alsa.jcu.cz/ . Neither one appears to ship with any test program, so there's no easy way you can tell whether your drivers are working or not.
There is also a commercial version of the OSS drivers which costs $30 (slightly more for certain audio cards.) Hit http://www.opensound.com/ . There are more supported cards in commercial OSS than in free OSS.
The ALSA driver set is compatible with OSS so that you can run OSS programs with ALSA installed, but apparently not in full duplex. Pd can be compiled for "OSS" or "ALSA"; in the distribution it's compiled for OSS. To remake Pd for ALSA look at the makefile in pd/src.
On the Red Hat distribution at least, OSS is started using the "sndconfig" program. It's harder to stop it. You can see if the audio drivers are running using "lsmod" (as root.) If you see something like:
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 2then OSS is running, and if all you see is:
eepro100 3 1 (autoclean) aic7xxx 23 2then 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.
The file, "/etc/conf.modules" 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.
You have to install both the "driver" and "library" distributions from the site, http://alsa.jcu.cz . The file, "INSTALL" in the ALSA driver distribution should describe how to install ALSA, except for the mysterious line: "5) Edit your /etc/conf.modules (look to kerneld/kmod support section)". I never figured out just how I was supposed to edit "conf.modules" but I found out how to start ALSA manually. For me, running an opl3sa2, it took the commands,
depmod modprobe snd-opl3sa snd_port=0x370 snd_wss_port=0x530 \ snd_midi_port=0x330 snd_fm_port=0x388 snd_irq=5 \ snd_dma1=0 snd_dma2=1 insmod snd-pcm1-oss(the last line was to get OSS compatibility. ALSA can emulate OSS, so that you can run pd compiled for OSS with the ALSA driver, but you apparently won't be able to use audio input and output simultaneously if you do that. See the file, "FAQ" in the ALSA distribution.)
For some sound cards ALSA can determine the I/O addresses automatically, so that a simple "modprobe snd-xxx" will suffice in place of the example I gave above. The "INSTALL" file may help; also, you can just install OSS and copy its settings, or even boot NT and see what Gates did. Note that "wss" is sometimes spelled "mss". None of the documentation says what either "wss" or "mss" means.
Some sound cards are supported better than others in Linux. In addition to full versus half duplex, there are differences in how the driver communicates with Pd about FIFO status. If on an audio card you get "audio stuck" messages, you can try using the "-frags" and/or "-fragsize" flags (default, 4 and 11) which force Pd to use a clunkier but more widely supported API for controlling the FIFO.
In the "frags" model, Pd's input and output buffers are divided into a number of fragments of a given size. The "fragsize" argument is by powers of 2, so that "11" means 2048-byte fragments, which is 512 sample frames, or about 11.6 msec at 44100 Hz. So "-frags 4 -fragsize 11" gives an audio latency around 46 msec.
Here's a rundown on my experiences with sound cards so far. See also Guenter's audio page.
The opl3sa2 in particular is an ISA device and you have to deal with I/O addresses and all that.
You might well have to do the "-frags" thing (see above) with oplxxx.
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:
joystick black green red blue bidirectional line-out mic-in line-inI think you can load the es1370 driver on the fly simply by typing
modprobe es1370(perhaps after running "rmmod" on some other driver as described above.) To have your computer automatically load es1370 on startup, put the lines,
alias sound es1370 pre-install sound insmod sound dmabuf=1 alias midi es1370in /etc/conf.modules, or run sndconfig (as root) and get it to do it somehow.
To make the card do quad you have to download and compile Guenter's es1370 control program, which is part of the "small patch" you can download from http://gige.epy.co.at/pd/cards.html .
The really tricky thing about quad is that the regular "stereo" outputs move to the black jack and the new "back" channels appear on the regular line output (green.) What's more, the back channels are normally mixed into the front ones (or is it vice versa?) so you'll have to play blind man's bluff with aumix for an hour or so to get the four channels to emerge separately.
My own version of Guenter's control program can be downloaded from http://www.crca.ucsd.edu/~msp/Software/audio-es1370.tar.gz.
Apparently the driver doesn't support SPDIF input, only SPDIF output; only the analog inputs appear on the "mixer."
Hit http://www.crca.ucsd.edu/~msp/Software/audio-rme.tar.gz for my version of Winfried's driver and test program which works with the current release of Pd (0.27).
With this card there is no FIFO size control at all within Pd; it's set using Winfried's test program. As far as I know the RME9652 is the only professional audio hardware you can run with Pd.
With the RME option, you can use "-soundindev" and "-soundoutdev" flags to select which input and output devices to use (for instance, the AES/EBU ports are devices 25/26).
Mark Danks's GEM package is available from http://www.danks.org/mark . Download this to extend Pd to do 3-d graphical rendering using Open GL
pd [options] [patches to open]although you may have to specify a path so your command interpreter can find Pd (OS dependent.) The options are as follows:
-rwith additional options for NT:-- specify sample rate -nodac -- suppress audio output -noadc -- suppress audio input -nosound -- suppress audio input and output -inchannels -- number of audio input channels (0-8) -outchannels -- number of audio output channels (0-8) -audiobuf -- specify size of audio buffer in msec -nomidiout -- suppress MIDI output -nomidiin -- suppress MIDI input -path -- add to file search path -open -- open file(s) on startup -lib -- load object library(s) -font -- specify default font size in points -verbose -- extra printout on startup and when searching for files -d -- specify debug level
-listdev -- list audio and MIDI devices -soundindevand for Linux:-- specify audio input device number -soundoutdev -- specify audio output device number -midiindev -- specify MIDI input device number -midioutdev -- specify MIDI output device number
-fragsHere are some details on some of the audio options (but see also the next section on file management.)-- specify number of audio fragments -fragsize -- specify audio fragment size