Audio Programming Assignment

Audio Programming Assignment 2: Drone challenge 1
Audio Programming
Assignment 2: Drone challenge
The mark for this assignment will be worth 30% of your final course mark.
Assignment overview
This assignment is designed to let you experiment creatively with some of the basic audio DSP elements
we have covered so far. You will submit a single Juce project that uses the Audio Plug-In template to
render audio, although the focus will be on the standalone application build target. The application
should generate
drone music. For us, that means that we can create sounds with a relatively static
set of synthesis elements and we don’t necessarily have to worry about constructions such as notes or
rhythms (things that would often be determined outside of a plugin in the MIDI data). Make sure
you think about how the sound will evolve over time, and draw the ear in to the detail. Note that
the software should not be controlled by the user (no sliders, dials, buttons, etc): once the program is
running, it develops by itself.
The assignment will be marked in relation to creative sonic/musical exploration of the programming
(45%), well implemented code (35%, including considerations of efficiency, structure, absence of redundant code, etc), readability (10%) and comments and documentation (10%).
Elements to submit
Your software. To keep submission files small, please just include the Source folder and
Projucer project file, and any other files necessary to build and run the software
if you have any of your own files being used that are not in these directories). You do not need
to submit the Build folder or the JuceLibraryCode folder. Make sure that your own header files
are included in the Source folder.
A 2-4 minute audio recording of your project (see below on how to do this if you’re not sure).
This can be a WAV or MP3 file.
A short 400 word report that outlines your approach to the drone piece, including a simplified
flow chart or block diagram
representing the structure of your audio elements (e.g. identifying
oscillators/filters/modulators, etc and showing how they relate to each other). Note that the
report stay focused on the sonic elements rather than the specifics of the coding, as these elements
should already be addressed in your code comments. This report should be a pdf.
Coding objectives
Create a piece of software with the Juce Audio Plug-in Template that generates an engaging drone
piece. As part of this, your code should incorporate the following:
1. At least two classes that you have created (not including the Oscillator examples that we have
looked at so far). These might be classes that extend the oscillators, or classes that include several
oscillators together into a larger class, or something else of your own devising. The classes should
be defined in a separate header file with a relevant name (or multiple header files as appropriate).
2. At least one
std::vector<> that includes multiple instances of a particular class (your own or
perhaps a Juce class).
Tom Mudd [UoE DRPS: MUSI11066]

Audio Programming Assignment 2: Drone challenge 2
3. At least one instance of the
juce::IIRFilter class, or potentially another filter of your own
These are the essential elements, but you will likely need a range of other elements too to create a rich
It is very important that you document comment your code judiciously. Comments can help you to
obtain marks for the assessment elements even if the code is not fully working for certain aspects. You
should include brief comments that explain:
the role of any variables that you define,
the function of particular classes,
the role of particular functions, noting both the type of data that is accepted as an argument (if
relevant), and the kind of data returned (again, if relevant).
for classes and functions, use /** … */ to create a documentation block, e.g.
* Convert MIDI pitches to frequencies in Hz
* *
@param note midi note (60 = middle C, 69 = 440 Hz)
* @return frequency in Hz
float midiToFrequency ( float note )
// …
Tips for engaging drones
Some potentially interesting aspects to consider for creating drone pieces:
Modulation can be very interesting for creating richer timbres and evolving those timbres over
time (see LFOs below). You have already tried out phase modulation, but you could also explore
frequency modulation, amplitude modulation, or experiment with other parameters to see what
works well.
Low frequency oscillators (LFOs) can be very useful for making parameters change slowly
over time (e.g. volumes, frequencies, timbral parameters such as modulation frequencies, modulation indexes, filter cutoff and resonance parameters, or any other aspect that might be sonically
engaging to vary). These are easy to create as we already have oscillator classes that we can
set the frequencies for and apply however we like. Note that you can also use LFOs to vary the
rate and intensity of the effect of LFOs (e.g. like depth or modulation index as with the phase
modulation example), and have other LFOs modulate those LFOs and so on, creating much less
predictable patterns than simple ramps or sine sweeps. You could also think about how you
might generate different shapes, e.g. the square of a sine function has a different shape from a
regular sine function that may be useful. If you want things to happen discontinuously rather
than continuously (e.g. regular jumps instead of a smooth link), you could think about doing
something like scaling the output of a phasor ramp so that it goes from 0-9, and then forcing
this into an integer range. You could then potentially use this as an index to an array (e.g. of
oscillator frequencies for regular pitch changes).
Tom Mudd [UoE DRPS: MUSI11066]

Audio Programming Assignment 2: Drone challenge 3
Beat frequencies, the rhythmic pulsing caused by two tones that are close in frequency, are an
interesting way to add movement and texture to a drone piece. If two frequencies differ by N Hz,
you will hear a rhythmic pulsing at N Hz. This technique is also used to create thicker synthesis
sounds, by having two or more oscillators per note, with one slightly detuned from the other.
Resonant filters can be very useful for highlighting particular frequencies in an input sound,
particularly where the cutoff frequency for the filter is moving in interesting patterns. The Juce
IIRFilter class is very helpful in this respect, alongside the IIRCoefficients class and the member
functions like
juce::IIRCoefficients::makeLowPass(sampleRate, cutoff, resonance).
Creating lots of a particular class that all behave slightly differently can be an interesting way to
dense undulating sounds. The
std::vector<> can be very useful for this. If, for example, you
want to create many instances of a MyOsc class, you can create a single
object called something like myOscs, then add as many oscillators as you like to this object by
push back( MyOsc() ); multiple times to add elements to the array. You can then access
each MyOsc using an index:
myOscs[0], myOscs[1], etc. Remember that to use vectors you will
need to include the relevant library:
#include <vector>
Stereo: try exploring panning in your DSP code. In Juce we are creating an array for each
channel. By changing the relative volumes of different elements in the two channels you can
position elements in the stereo field. You could also think about using LFOs to automate the
panning position.
Marking criteria
The assignment will be marked in relation to creative sonic/musical exploration (45%), well implemented code (35%, including considerations of efficiency, absence of redundant code, etc), readability
(10%) and comments and documentation (10%).
The criteria for marking this assessment is based on:
1. Is the final audio result aesthetically engaging?
2. Does it evolve in a way that could hold a listeners interest over a longer period of time?
3. Does the code compile and do what it is supposed to (as articulated in your short report)?
4. Is the code well documented and explained with comments?
5. Is the code neatly laid out? Have a look at this Juce style for tips on clear writing, and adhering
to Juce coding standards
6. Is the code efficient, or are there superfluous elements? Try to adhere to the common coding
mantra: Don’t Repeat Yourself (see the above link for more information).
7. Have you explored ideas beyond the basic examples presented in lectures and tutorials?
Recording an excerpt from your software
To create a stereo audio file example of your software, you can use a DAW. These instructions are for
generating an audio file with Reaper:
1. Make sure you have build your project as a VST or AU component.
2. Open Reaper, start a new project, and go to Item
-! Insert Virtual Instrument on New Track.
Tom Mudd [UoE DRPS: MUSI11066]

Audio Programming Assignment 2: Drone challenge 4
3. From the menu, look for your plugin and click OK (it may be under the New section, or otherwise
check the AU/VST3 sections)
4. You should now hear your program playing. Select an amount of time to record for by dragging a
selection at the top of the timeline as shown in the image below. You will want to select between
2-4 minutes for this submission as you prefer.
Figure 1: Create a selection in the timeline to determine how long the recording will be
5. Go to File
-! Render…
6. Make sure you select
Source: Master mix, and Bounds: Time selection as shown here. Use
Browse button to choose where to save the file, and give it an appropriate name with your
exam number.
Figure 2: Example Render settings
Submission details
You should submit your code, report (pdf) and audio file (wav or mp3) as a single .zip file. The zip
filename should include your
exam number (e.g. B******), so your final file will be called something
B123456 AudioProgramming Assignment
Selected Drone Listening
Eliane Radigue – L’^ Ile Re-Sonante
Eliane Radigue – Triptych
Tom Mudd [UoE DRPS: MUSI11066]
Audio Programming Assignment 2: Drone challenge 5
Roland Kayn – Rhenit
Eleh – Living Space
Caterina Barbieri – Bestie Infinite
Giacinto Scelsci – Quattro pezzi su una nota sola
Tom Mudd [UoE DRPS: MUSI11066]