Difference between revisions of "User:Jrowell/220C"

From CCRMA Wiki
Jump to: navigation, search
Line 36: Line 36:
The bass is controlled by the same Markov process as pads2, but with a different weighting system.
The bass is controlled by the same Markov process as pads2, but with a different weighting system.
[https://ccrma.stanford.edu/~jrowell/220c/bass.ck Example framework which moniters bass]
===Chord Progression===
===Chord Progression===

Revision as of 16:03, 12 June 2012

Charles is an attempt to make a non-repeating randomly driven music/soundscape generator. It was written by Jeff Rowell for the Spring 2012 iteration of Music 220C, and hopefully will be used in performance as part of the Burning Man Art Car Charlie the Unicorn

Zip of all playable files from 6/12/2012

Demo of program playing, 6/12/2012

Project Overview

The goal of this project is to create a program that, when executed and then left alone, will generate unique music for the length of the run time (ideal run time for installation will be 3-5 hours).

One of the problems with creating a generative and non-repeating music program is how to keep all the instruments on the same page sonically. My solution for this is to have a hierarchical program with several public classes to control the instruments. The base level holds the global variables (what level of intensity the music is at, what is the tempo). The next level consists of two programs- Drums, and Pitch. "Drums" holds the control variables for the drums- which sounds are playing, what the density of sound is, and then adds or removes shreds accordingly; Pitch holds the variable to control the chord progression and tonal center. Chuck file to determine phase

The other main problem with having the program being generative is avoiding repeated sounds without relying on an overly large sample bank. To get around this problem, there are three kind of pitch instruments- generative ChucK based instruments, sample based instruments relying on variable playback, and sample based instruments based on pitch shifting.

Non-Melodic Functions

Drums.ck moniters the "mood" of the piece at the beginning of every phrase. If the upcoming phrase calls for a higher density of drums, it uses Machine.add to call the appropriate drums code. Correspondingly, it uses Machine.remove to remove the proper code. The timbre of each drum is only selected at the sporking of the drum codes, and so will change only when an instrument encounters a section in which it is removed and added again later; merely changing phrases will not change the timbre of an instrument.


Steady Drums

Steady drums (mainly the kick and snare) are easy to implement; When the shred for a steady drum is sporked it randomly selects a timbre and then plays that sound in a steady loop until removed by Drums.

Random Drums

Random drums (toms, aux percussion) are implemented by using a basic Markov code to select the time between hits based upon the previous time between hits, using a timber randomly selected at the sporking of the shred.

Patterned Drums

Patterned drums (hi-hat, aux percussion) have a number of pre-set rhythmic patterns held in an array. The patterns are then selected using Markov chains; once one is played through the next is selected.

Melodic Functions

The harmonic tracking functions much the same way as the rhythmic tracking. The main harmonic control (pitch.ck) holds a variable to declare the main tonality of the song, and then an additional variable to hold the chord progressions the music will run through. The harmonic aspects also follow the general density rules outlined for the drums.


There are two harmony controls- pads and pads2. Each is responsible for adding and subtracting melodic instruments, but they achieve it in different ways- the goal is that between the two methods there is a pattern created which is non-obvious and interesting to the ear.

Pads is deterministic in its controls- it looks at the energy level of the piece, and adds or subtracts a pad accordingly. For example- if the energy level switches to 2, pads will remove it's pad if there is one playing or do nothing if there is no pad playing; for energy level 8 it will add a pad if there is nothing playing, but will do nothing if there is already something playing. For a few energy levels, it will replace the pad if one is playing but do nothing otherwise.

Pads2 is probability based. If holds a Markov table, where the probability for each state is an integer modified by the energy level of the piece. In this model, the probability of the pad being added if there is no pad playing increases with the energy level and the probability of the pad being removed decreases as the energy level increases. This adds to the general shape of the piece, but makes it more difficult for the listener to determine exactly what will happen.


The bass is controlled by the same Markov process as pads2, but with a different weighting system. Example framework which moniters bass

Chord Progression

The chord progression is held in pitch.C and controlled by "progressions.ck". It holds a bank of common four measure chord progressions (for example i,i,i,iv, i,VI,III,VII, i,VII,VII,i, etc), and a probability chain for each one. The current chord progression influences the choice of the next progression to ensure a smooth and logical sounding flow.

Methods of Generation


Using built in unit generators for Chuck, and some basic FM synthesis, timbres are created and played. This was the preferred method of generation in my original conception for the program, but there are some notable limitations. Due to the computationally intense nature of this method, my system quickly runs out of power if more than one or two shreds are running concurrently leading to some nasty clipping and audio drop-outs. In addition, due to the precisely periodic nature of the output, if the same instrument is chosen by both of the pad controllers, it results in severe clipping, even with the limiter and compressors I have running to control the output. Most pads are generative, while most of the bass notes rely on other methods. Example Chord, using unit generators

Pitch Shifted

Using pitch shifting on single note samples allows for variation without require a huge database of samples, but has it's own limits. While it can be convincing on low notes and within small shifts, large jumps and higher sample notes start sounding quite odd quickly. However, it is quite useful for low samples which have an obvious attack that precludes changing the playback rate. Example Bass, using Pitch Shifting

Playback Tempo Shifted

Using pre-recorded samples of a standard note while varying the playback rate to produce different notes is the main method I ended up using for bass generation. This method is light on the processor, while avoiding the odd artifact sounds often produced by delay line based pitch shifting. However, if the note sampled has an obvious and characteristic attack or distinct periodic variations that would be shifted, it is best to use other methods. For example, the playback of Moog Synthesizer samples works well tempo shifted, but a note played by a bassist is distracting, as the attack keeps varying in speed. Example Bass, using Tempo Shifting


I am fairly satisfied with the results at this point. The program plays with generally good sound quality, and it fulfills the stated goal of a constantly shifting rhythmic soundscape. That said, there are several modifications I will continue to work on-

Grouping Sounds

As I continue to add new instruments and rhythms into the database, I need to implement a method that groups them by texture to avoid conflicting sounds. It would function similarly to the density variable currently implemented, and track a scale from natural sounds to highly artificial and compressed sounds.

Shifting Tempo

It has been suggested, and I agree, that having the ability to shift the tempo while playing would add interest. There are a number of ways to implement this, but unfortunately the architecture of the current control structures doesn't allow it. I hope to have tempo shifting be a feature by mid-July, but doing so now would not allow any sound demos to be played.

Adding more Instruments

The best way to allow the program to play longer without becoming stale is to add new instruments; this will always be a continuing project.

Log Updates


-basic architecture coded

-drum sounds added

-mood control variable implemented


Excerpt from running of program on 5/1

-melodic controls added

-basic instrument types added


- Two types of harmony sounds have now been added, arpeggiators and block chord players. They both hold an array of all the chords that can be dictated by the harmonic progressions, and either play them back at various tempos and in various voices. As currently played, the selection of voice and tempo is dictated by a pure random number generator. The addition and subtraction of the harmonies is determined by the current energy level of the piece combined with the length of time the shred has been playing.


- The bass at this point consists only of tones which play the bass of the chord in a pulsing or non-pulsing rhythm. The introduction and removal of the bass is controlled by the current energy level of the piece.


- The bass and one of the pads controllers now work on a probabalistic level- The energy level of the piece is used as a variable in a Markov chain; when the energy level is low there is a low probability of adding or switching the bass, when there is a mid level of energy the odds of adding or subtracting are medium, as is the odds of switching the sound. When the energy level is high there is around a 95% chance that that bass will be playing, and if it is already playing there is a good chance it will be switched.


-bass and effects using pitch shifter and varying the playback rate on SndBuf implemented


"Final" version of program

Demo of program playing