buttons and handles

CCRMA Stanford University

Music 250 - Physical Interaction Design for Music

Lab 1: Mappings, Modes, Sound Generation, Pd

Due Wednesday October 3

1. Download the lab 1 Pd patches

Save lab1.tar.gz into your 250a directory.

Uncompress the archive

~> cd 250a
~/250a> tar xzf lab1.tar.gz

2. Play around with the Pd patches

If you weren't at the console during Wednesday's class, download the .pdsettings file & the instructions in 2) from the PD lecture

Open lab1.pd. Play around with this patch. You should be able to exhaust its musical potential in a matter of minutes; reflect on its strengths and limitations.

~/250a> cd lab1
~/250a/lab1> pd lab1.pd

Also try to understand how it works as a piece of software. (But please don't get hung up on the Pd arcana - as always, if you get stuck, ask for help rather than waste time.)

Pd Documentation

Right-click on any object to get a contextual menu including "Help," which opens that object's help patch.

Right-click on a blank portion of a Pd patch. Now when you select "Help" you get a list of Pd's built-in objects, arranged by category.

In the upper right hand corner of each Pd window is a "Help" menu. This accesses the Pd tutorials as well as some online reference documentation.

3. An exercise

Compensate for your lack of rhythm. Implement some form of averaging or error correction on the collected tempo measurements.

4. Design a different musical interaction

Here are some ideas of changes that might make the patch more interesting:

  • Add rhythm quantization: force the determined tempo to be a multiple of some base number

  • Load in a larger collection of samples. (See the kit in the samples directory)
    • Implement a mechanism to switch among banks of samples
  • Multiple gestures to one result: design a way for the parameters of each triggered note to depend on multiple keypresses. For example, maybe only the space bar triggers notes, and all the other keys determine parameters of notes.
    • Set multiple parameters modally, as volume works in the sample patch
  • One gesture to multiple results
    • Use Pd's "metro" object to trigger a steady stream of notes. Now you have two new parameters: repetition rate, and whether the metro is on or off.
    • Use Pd's "counter" object to step through a cycle (of samples, parameter settings, etc.)
    • You could combine "metro" and "counter" to build a rudimentary sequencer that can step through a rhythmic pattern
    • Invent a mechanism to record short sequences of keypresses and play them back in time.
  • Incorporate looping or other interactive controls over the soundfile playback
  • Use Pd's "spigot" object to route control information to different parts of your patch at different times
  • Use some additional signal processing such as a delay line, reverb, tremolo, etc. This gives you more parameters to control.
  • Use a totally different form of sound synthesis, such as FM, granular, or physical modeling.

We recommend that you pick one or a small number of these and work on it in depth, iterating on both the program/test/debug cycle as well as the design/implement/play cycle to craft something that has actual musical potential or is at least more fun to play. If you have an existing idea for your class project, you could use this lab to start thinking about implementing some of the modes and mappings. By all means, if you're inspired to try something else, go for it. If you'd rather spend today getting more of a broad sense of Pd's capabilities, feel free to work on many of these suggestions.

5. The Pd Community

Although Pd is clunky and has lots of usability issues, there is a large, dedicated, and very generous community of Pd users on the Internet. Do some web searching (e.g., with a search engine, or else starting from some Pd-specific resources - see the 'resources' page for some places to start) and look for interesting Pd externals and/or patches. Download, install, and play with at least one. Can you incorporate it into what you programmed in part 4?