plays back at Middle C. By using the 6th encoder, the user can adjust the Tune parameter, and move the
original sample to play back on any key on the keyboard.
2 Modules
The Wumpus consists of 5 top level modules: Control, Notes, Echo, Visualization, and Audio. We coded
the first four, while the last was kindly provided by the 6.111 staff.
Figure 2 displays the topology of these modules. The design can be separated into two halves: the
sound handling half, which includes notes and echo and the control half, which includes visualizer and
control. Damon implemented the sound handling half while Mark implemented the control half and both
worked on integration. The interface between the two consists of the echo controls, and of the parameters
stored in a memory in notes, which control writes and sees return data from, to play and check allocation
of notes respectively.
We should define three words before delving into module descriptions, for the sake of clarity. A
sample is the entirety of a recording into the Wumpus. A frame is a single value of the sample at a given
time, and a window is a small sequential subset of frames in the sample.
2.1 Notes
The notes module takes in audio data from from ac97 data and outputs summed polyphonicand playback-
rate-shifted audio data on data out.Internally, this module consists of four submodules which work to-
gether to sequentially create and sum the desired frame for each individual note being output at a given
time. Although the mechanism used to do this has very low overhead per added note, we decided to limit
the number of notes to 8 to avoid degradation of the playback quality. The four submodules of the notes
module are taylor, notemem, frameprep, and accumulator. The notemem module stores parameters (val-
ues which are constant throughout the playback of a single note) and variables (values which can change
on any given frame) describing each note. The parametarized description of each of the 8 notes is fed in
series to frameprep, which provides taylor with the current, previous, and next sample in relation to the
note’s current playback location. taylor uses these to do a taylor expansion of the sample and provide
the desired frame, and feeds new variable values to notemem (signalling notemem to move onto the next
note). accumulator sums the serially created frames for each note, and outputs this value on data
out.
This module is fairly simple in terms of the number of lines of code, but proved to be very hard to debug
due to the high level of interdependence between modules. All modules in notes signal off the previous
module they depend on for input values. The way this is done, it creates a cycle which goes through all
notes in the mimimum number of clock cycles given the delay of each module in the cycle.
This module construction differs significantly from the original plan, which involved ten copies of a
single note module, which would all timeshare a top-level sample module for memory access. Parameter-
ization of each note, and creation of linemem, described below, allowed for the much simpler, if somewhat
less straightforward design used in the final implementation of the Wumpus.
2.1.1 Taylor
The taylor module takes, all in parallel, three concurrentframes, a ready
frameprep signal from frameprep,
and all parameters and variables stored in notemem. At ready frameprep, taylor uses the current and pre-
vious frames to linearly interpolate the value of a virtual frame period frames from the previous virtual
frame for the playing note. taylor then determines the integer position, n, and fractional offset position,
delta, from period, and returns these to notemem as it signals taylor
done. The taylor done signal also
3
