Day One
One of the most amazing things of PureData is that it is so accessible. Even people with no programming experience whatsoever, can build from scratch (very) basic patches after one day that make funny sounds when a key is pressed, or the mouse is moved.
On the first day we looked at Pd types and components, floats, symbols and lists, and objects, numbers, sliders and so on.
Starting with basic arithmetic we investigated making adders, counters and playing with a little trigonometry with sin and cos functions.
We talked about the process of a Pure Data patch, how messages and numbers flow down the worksheet through objects and how to make them do so in the correct order by understanding evaluation order and triggers.
Exercise 1
The Beetle Race problem is to create a pair of counters that randomly advance to simulate a race. A solution is shown below that demonstrates the need for and use of triggers nicely. On the left at the top is a receive unit that picks up and displays a symbolic message after "casting" it to make sure it is a symbol. That display is used to show the winner of the race.
When the GO button is pressed, a bang message passes to the trigger which sends the bang on to two further destinations in right-to-left order. The first of these is to a [0( message box. Banging this sends zero to both of the float objects used in the counters, resetting them back to zero. The other sends one to the metronome which takes over generating events. Each metronome tick causes both the counters to increment by a random amount between zero and three.
To decide when one of the beetles has won the value of its slider is compared to 126, one less than the maximum value. If it's greater than 126 we assume it's the winner and stop the game. Then we send out the message to display.
We briefly discussed whether the game is fair, and the problem of determinacy and logic in computer games and simulations.
Notes: The game is not fair because one player must always move first and there are a bagful of philosophical implications that can lead us into considering the nature of computationally generated random numbers, multi-processing and concurrency and all sorts of other things. Many of the group grasped this intuitively and made interesting suggestions to improve the game.
In the afternoon we talked more about lists, GUI components, input and output using keys, joysticks and other basic HID controllers.
Exercise 2
To make a ball spin around but gradually slow down we needed to understand how to manipulate and divide time.
By using a counter to keep track of how long the ball has been spinning we can change the rate of the metronome.
When the speed of the ball drops below a certain point we want to stop the game. This happens when the metronome period is greater than a threshold, 200 in the solution shown. Two solutions are given in the Pure Data files here. One is a more elegant version that uses the properties of the latest version of sending, which can re-route its destination dynamically. For Pure Data versions less than 0.40 the other file that uses select should be loaded.
Day Two
We looked at simple functions of time at audio rates, how to shape waveforms and what frequencies are created by doing so. Essential units like delays, filters, signal generators and tables came into play, so by lunchtime most of the group knew how to build basic synthetic sounds and how to load, save and process existing audio data.
The first practical was to create a random melody generator as a musical toy. This refreshed the previous days work in the message domain as we explored how to control the pitch and amplitude of a single sine wave. Our collective solution that we worked out on the main screen is here.
We had a little time to briefly look at HID, MIDI and other I/O devices. Here's an example of using computer keys to play notes, and a "Theremin" using a joystick to control amp and frequency.
After Lunch I spent a couple of hours on the principles of synthetic sound design. If the day had been longer, or less beer had been consumed the previous night, we would have moved on to games sound design proper, but the group felt an itch to get hands on playing with some musical uses of Pd, so we decided to move on to the final group project. This practical was to construct a drum machine capable of playing some rhythms using a bass, snare and hi-hat instrument.
Exercise 3
First we discussed the nature of each instrument, the frequencies and timbres involved and how we might add dynamics to shape our signals. The snare is an interaction between a tight skin, a coil that contacts the skin, and a beater/stick that hits out the rhythm.
The sound is a composition of some pitched and some noisy waveforms, so we looked at how to use noise~ and osc~ units to build up a layered sound.
The bass is a low pitched, more heavily damped skin, whose pitch is a function of the pressure of the beater on it. We considered FM and how we might move the frequency of an oscillator to best emulate the effect we wanted. Finally, a hi-hat is a pair of small cymbals that clash together and it has many high and complex frequencies.
To get the sound of a hi-hat we thought again about what oscillators and noise sources could do together if we mixed and modulated them in different ways, and how those methods corresponded to physical attributes and actions.
It was very interesting that every students/groups solution was unique. Music DSP is such a fun subject to explore because everyone comes up with a different twist that reflects some level of understanding. And because the goal of music isn't as precise as numerical DSP for industrial applications, every take is basically correct so long as it fulfills the broadly defined artistic aims.
In other words, for me, the exercise was a resounding success, not only did everyone create a working instrument each one worked well and had peculiar parameters of its own.
