Thought I'd take some time to show you the PureData patch that I created for this piece (Apologies for a long post length). The piece was performed this past Thursday and the performance went great, despite me not having tried it out on the studio's new MacBook Pro until the day of the concert.
In the top left corner is the top of the patch hierarchy, which shows the master sound level of the piece. (Click on an image to enlarge it.) To the right is the "pd engine" where I keep all of the patch's internal logic. And below is what I call the dacbox. Any audio that is thrown to "dac_left" "dac_right" or "dac_out" is caught, added together, and multiplied by the master_vol before sending it to the digital to analog converter (i.e. the speakers).
Under chroma you have the innerworkings of the following idea: The patch listens to the gameboy for discreet pitches (this is what "fiddle~" does in the picture) and then will play those pitches, at random, until it is told to stop. the subpatch "chroma_memory" pictured here takes care of the first problem--listening to the gameboy. Once fiddle~ finds the midi value of the note played, we mod that value by 12 (since there are 12 tones in a chromatic scale), and OR a bitwise representation of that number to the current representation of previous notes heard. (In hindsight, storing those values in a pd table would have been clearer to understand, but this approach does appeal to the bit-twiddling geek in me.) Chroma_memory can also listen to a chord progression instead using the "receive chroma_chord" object.
Chroma_selector on the right determines which note will be played at what time. Loadbang starts the metro once the patch is loaded, and the metro's tempo is being constantly changed by the random 1000 object (where the 1000 is in milliseconds). At these random time intervals, random 12 is asked to generate a note between 0 and 11 which corresponds to one of the pitches in the chromatic scale.
Chroma_validation makes sure that the note chroma_selector has chosen to play (left inlet) is a part of the subset of notes that chroma_memory has said are OK to play (right inlet). If the selection is valid, the appropriate sound file is loaded, panned (via chroma_panner not pictured here), and thrown to dac_left and dac_right.
The fft subpatch takes whitenoise (aka "noise~"), and convolves it with the signal coming from fft_timbre (in this case, vocal harmony). The twist is that conv_lvl determines how much like the fft_timbre the whitenoise actually sounds. A similar crossfade relationship is happening between chords and strings. I'm not showing the fft-analysis subpatch here because it's identical to the timbre-stamp help example in pd.
These are my midi controls, using my Axiom25. Most of the ctlin objects are assigned to faders except for the stuff at the bottom which is assigned to buttons. Button 20 determines whether chroma listens to the gameboy, or to the chords. Button 22 starts all chord progressions, while 23 stops them all. Button 24 starts the chords without counterpoint.wav, while 25 starts only counterpoint.wav. When I say chord progressions, I mean there is a soundfile for gameboy harmony, a soundfile for string harmony, a soundfile for vocal harmony, and of course the chords sent to chroma_memory. Counterpoint.wav sounds like this:
This last subpatch is just triggering the three wav files at the bottom using various techniques. The graphical bang labeled "introduction" plays the files one time through, whereas there is also a random loop (complete with killswitch), and "end loop" which is a different loop for the end of the piece.
Even seeing every part of the patch, the final product is hard to conceptualize without hearing it. All the patch really does is set up ways for me to perform, there is no actual score here. I'm hoping to record a studio performance of the piece so I can share it here, but in the meantime let me know if this patch explanation made any sense at all :)
