POST CS Building Amsterdam NL.
Location: Mediamatic, Amsterdam Date: Feb 3-4 2007 Organisers: Klaas Kuitenbrouwer , Debora Meibergen Tutor: Andy Farnell Assistant: Kostya Leonenko Duration: 2 days
The previous day Kostya and I ran through some exercises which we used to teach the first session. The idea was that they be easy enough and that a correct solution to each could be obtained using only the knowledge gained from the material in that session.
The first of these was the fundamental "heads or tails?" problem, to use a random number generator to create a 50:50 probability of an event with one other alternative and output a report. Another was called "Beetle Race".
During the morning 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 puredata patch, how messages and numbers flow down the worksheet though objects and how to make them do so in the correct order by understanding evaluation order and triggers.
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 a 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 breifly 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 bagfull of philosphical 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. There was a choice of several exercises to take for the second practical session. One to make a roulette wheel, one to make a simple desktop calculator and another to process a list of football scores. Most of the group chose to make a roulette wheel so I will include that one here.
Exercises 2 To make the 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 puredata files here. One is a more elegant version that uses the properties of the latest version of [send] which can re-route its destination dynamically. For puredata versions less than 0.40 the other file that uses [select] should be loaded.
On the second day we started a little later, it being a Sunday morning, but after copious coffee the pace picked up quickly again as I tried to cover many hours of DSP 101 in a single session. 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. 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 rythmns using a bass, snare and hihat instrument. Exercises 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 rythmn. 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 is 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 fullfills 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.
Here are some drum sounds the group made using puredata.
Finally here's a little patch with them tidied up by me to showcase them with a sequencer making beats.
A tense moment as we cover basic bomb disposal.
Main Page