You already learned how to create subpatches in Pd in 2.2.4.4 . Now, you'll learn how to use them wisely.

Let's say you have this patch:

patches/5-1-1-1-subpatch1.pd

You could tidy it up by storing everything that doesn't require immediate access in a subpatch:

patches/5-1-1-1-subpatch2.pd

It also makes sense to store the contents in several subpatches, in case you want to edit a specific part of it later.

patches/5-1-1-1-subpatch3.pd

You could build a certain algorithm (here: random lines) for a patch that could be used in different places:

patches/5-1-1-1-module.pd

A subpatch like this is called a "module".

If you have a subpatch that can be used universally, like the following one, which records two seconds in an array, then plays back the sample at a certain speed with variable amplitude:

patches/5-1-1-2-abstraction1.pd

...and you want to use it in different locations, then a problem arises: once the subpatch has been duplicated, you have to rename the array and enter a new input (for the speed). Instead you could make an abstraction out of it; this is a patch that is stored as a separate file and can be retrieved with a multiple of variables.

Take the subpatch from before and save it as "record.pd". Then open a new patch and save it as "main" in the same directory as "record.pd". Then create an object called "record":

"record" does not actually exist as an object in Pd. But if a patch with this name (plus the suffix ".pd") exists in the same directory, an object can be created that treats this patch like a subpatch.

An advantage of this lies in the variables. Reload the "record.pd" patch (File Open). You can write variables in form of "$1", "$2", etc. inside objects. Let's define variables for the array name and the speed:

Now you can write the "record" object in the "main.pd" patch again, this time with two arguments for the two variables; the first argument is the array name and the second is the playback speed.

The volume, which we want to change in the main patch as well, is set as an inlet just as for a subpatch.

But we've still got the problem that the array has to be given a unique name every time we load "record" in the main patch. There is a special option in Pd to solve this that generates an individual random number that can be used as a name for a certain patch. This is generated by $0. You could make the abstraction "z-number.pd":

A random number with an offset of 1000 is generated, and it counts up from there. Now, every time you call up the abstraction another number will be generated:

This is used to give the array a unique name. The conventional form is: $0-[arrayname]. You still need to set a variable ($1) for the speed. The volume should stay variable.

Finally, you can bring in graphic elements from an abstraction using the function "graph on parent". In the "record" patch, you can create a number box instead of an inlet for the volume, then right-click anywhere on the white surface Properties. Check "graph on parent" and then click "apply":

You should see a red rectangle. All GUI objects that are enclosed within this red rectangle will appear later in the object. Move the number box for the volume inside the red rectangle, save "record.pd", and then create the object in the new patch:

In the new patch:

You can change the size and position of the red field here:

"Graph on Parent" also works with subpatches.

Two important points: you can view and change the contents of an abstraction in the main patch (simply click on the object in the main patch). However, changes you make here will not be saved! Only if you open the abstraction itself as a normal patch in Pd are the changes you make actually saved. The second point is that $-variables can only be written in objects in an abstraction; $1 in a message box would just have the normal meaning of an input in the message box (cf. 2.2.2.1.4). For example:

And, of course, if you copy the main patch and want to use it elsewhere (e.g., in another directory or on another computer) you have to copy the "record" patch as well. You make abstractions available at all times by saving them in the "extra" directory in the Pd directory. All patches found saved here are always available as abstractions. Similarly, you can create your own directory containing abstractions and configure it to load automatically. You can set a path for this under File Path.

Many useful objects not included in the original version of Pd have been developed by programmers around the world since its inception. These objects are called "externals". Collections of externals are called "libraries", e.g., the zexy library or the MaxLib library. You have to put them in the folder called "Extra" and also integrate them into the startup process (File Startup). A new version of Pd called "Pd-extended" already includes libraries that expand the original version.

Pd can also be expanded through the use of additional programs. GEM is the most well known and is used to process video data and video files in a manner similar to how Pd processes sound and sound files. Additionally, open sound control (OSC) data from other programs that also have an OSC connection can be used in Pd. The Pd versions of some programmers have been expanded to such an extreme degree that they are barely recognizable as versions of Pd.

As mentioned in the previous chapter, Pd can be customized to a large extent. Let's create some useful abstractions.

For normal programming needs, a "dac~" object with a built-in volume slider, now called "dac":

patches/dac.pd

A DSP switch, called "+dsp":

patches/+dsp.pd

Graphic representation of a waveform:

patches/wave.pd

As abstractions:

a) Integrate the DSP switch into the "dac" abstraction as well as a mute on/off button.

b) Build a compressor.

c) Build a graphic representation for an incoming spectrum.

We have a patch with a subpatch called "test". In the main patch, we send the following messages to the subpatch using "s pd-test" from top to bottom:

"obj" creates an object; you enter the x/y-coordinates and the name of the object with its arguments. The same goes for the message box. The connection works like this: "connect [object number] [outlet number] [object number] [inlet number]". The objects are numbered in the order they are created, the outlets and inlets from left to right. Everything is initially set to 0. The message "clear" deletes the content of the subpatch.

Here is an overview of all the commands. At present (June 2008) some of these don't yet work:

This makes it possible - albeit in a fairly complicated manner - to, say, create a certain number of arrays with an abstraction, which cannot be accomplished in Pd any other way (cf. 3.2.3.1):

patches/ntables.pd

With this abstraction, you can create ten arrays in the subpatch with a size of 44100:

In this way, you could also create the subpatch in your main patch:

...is naturally also possible. Pd is merely a surface for a program in the programming language C, which allows you to write your own objects ("externals"). Here is a guide to help you do this: http://iem.at/pd/externals-HOWTO/