MUS174A Syllabus

mus 174a – audio studio techniques – fall 2017

cpmc 203 or 267 – tuesday, thursday 11:00 – 12:20

instructor – tom erbe – tre@music.ucsd.edu – cpmc 254

ta – jordan morton – jmmorton@ucsd.edu

topics

  • intro tour of the studio
  • analog & digital – signals – cables – patchbays
  • the mixer
  • microphones types
  • stereo techniques
  • instrument techniques
  • positioning
  • monitors types
  • listening techniques
  • tracking mixer configuration
  • monitoring
  • fx for recording (compression/eq)
  • logs
  • editing basic protools
  • fades and cross fades
  • layers
  • mixing basic mixing

books

required

1) bruce and jenny bartlett – practical recording techniques

optional

2) tape op magazine www.tapeop.com

3) bob katz – mastering audio

class requirements

  1. 2 studio assignments – 50% (25)
  2. final – record a piece in the studio – present it in class 10th week (play it, talk about it, discuss) the piece should stand by itself, and be independent of other media (that is – no soundtracks for film or video. no sound effects for theatre or video game, etc.). – 40%
  3. attendance, class participation – 10%

office hours

tuesday, thursday 3:30pm – 5:00pm

MUS177 MUS267 Syllabus

music 177/267 – custom programming for music – fall 2017

instructor – tom erbe – tre@music.ucsd.edu

•••••topic

this year we will be learning to program music software on an embedded processor. to do this we will cover 4 topics.

  1. c programming
  2. STM32F4/7 programming
  3. STM32F4/7 peripheral API (Cube)
  4. computer music/signal processing algorithms

••••schedule

  1. basics (basics and compilers – setting up a dev environment)
  2. ARM 1 – main(), initialization, GPIO, timers, and interrupts
  3. ARM 2 – ADC and DAC, analog connections (first assignment)
  4. dsp code 1 – amplifiers and distortion
  5. dsp code 2 – oscillators and sampling (second assignment)
  6. dsp code 3 – filters
  7. ARM 3 – high quality CODEC (final project)
  8. dsp code 3 – delay reverb
  9. ARM4 – other topics
  10. other topics

••••texts – software – hardware

  • C Primer Plus by Stephen Prata
  • Computer Music by Charles Dodge
  • DAFX by Udo Zolzer
  • ARM Cortex M4 Cookbook by Mark Fisher

Obtain either an STM32F4Discovery Board or an STM32F7Discovery. The F4 board is slightly slower and has only sound out, but should be sufficient for this class. The F7 board has a touch display and sound in and out.

STM32F407G-DISC1 $19.95

STM32F746G-DISCO $50.00ish

•••••my office hours

3:30 – 5 tuesday and thursday

•••••class requirements

3 projects of increasing complexity…. one is a final project. 267 students will be required to use their final project in a piece or for research.

SoundHack externals for Max7 (32/64 bit macOS) – ß1

I have completed porting 7 of 11 of my previous Max externals to the Max7 format as 32/64 bit universal macOS externals. This is beta software, so if any of you would like to try them, I would enjoy feedback (error messages, crash reports) if they don’t work on your machine.

If you would like externals for earlier versions of Max – please check the freeware section of www.soundhack.com

download – soundhackm7macbeta1

Pure Data patch for John Cage’s “Williams Mix”

Paper: The Computer Music Realization of John Cage’s Williams Mix

My current files for the performance version of John Cage’s “Williams Mix” can be downloaded here:
WilliamsMixPD201607
To run this patch, you will need the following PD externals:

– knob, within the flatgui distribution

– shuffle, within the motex distribution macos, windows and linux

– +binaural~, within the soundhack distribution (scroll down)

A sample sound file library is included here:
wmsounds
The sound file folder will need to be in the PD path. Once that is set, you can open wmmain.pd. It will seem to freeze, but it takes a while for PD to load 600 sounds into memory. If you do not have enough RAM in your computer, the piece may crash.


Screen Shot 2016-08-28 at 11.06.00 AM
To run the piece, click “Open” to open the score file, click the number corresponding to your speaker format (2, 2 binaural, 4, 6 or 8), and click play. The piece is 4:15 long. There is a button on the upper right which will “shuffle” the file choices for each subcategory. This should only be done when the score indicated the piece is “mobile”. This is my interpretation of Cage’s score as applied to this computer arrangement.

Using your own sounds
You will want to collect new sounds if you wish to create your own performance of the piece. You will want to consult Cage’s instructions for the sound collection (about 500 sounds in 6 categories are required). You will need to use 44.1k, monaural, 16 bit wave files to be compatible with this piece. Place them in folder which is in the PD search path.


Screen Shot 2016-08-28 at 11.08.28 AM
Edit wmfileopen.pd, creating a “wmtable bird2.wav” for a soundfile named bird2.wav. Repeat for each of your sound files. This may take some time!


Screen Shot 2016-08-28 at 11.10.29 AM
After this, you will need to modify the random sound selectors wmfileloadA.pd, wmfileloadB.pd, wmfileloadC.pd, wmfileloadD.pd, wmfileloadE.pd and wmfileloadF.pd. This means repopulating the selection tree for each of Cage’s 48 subcategories. The selection symbol will match the sound file name. Again, a time-consuming process.


Notes
It will take a lot of work and some PD expertise to use this computer realization of Williams Mix.

I am supplying this patch purely for educational and research purposes.

“Williams Mix” is 1/15 second too short….

I was just looking over the structure of “Williams Mix”. It is divided into 11 sections that repeat a rhythmic structure 5 6 16 3 11 5. In section 4, the 3 subsection is one inch short. I imagine when they were calculating tape start times for editing, they forget to carry the one. The 16 subsection is based on a 10.25 inch length, so is 164 inches. It starts at 1129.75 inches and ends 1293.75 inches. The 3 subsection is also based on a 10.25 tape length, so should be 30.75 inches. However, it ends at 1323.5 inches: 1323.5 – 1293.75 = 29.75. Earth shattering news?

So the piece shouldn’t be 4:15.8, but 4:15.866666…

noise study – structure

In James Tenney’s “Computer Music Experiences” article, he presents the following chart:

CME Fig 3.tifFrom this we can see 3 parameters, “note duration”, “intensity” and “bandwidth”. The subsequent values “mean pitch level” and “pitch range” are determined from the “bandwidth” profile. The charts that Tenney gives for “mean pitch levels” and “pitch range” don’t seem terribly useful at first glance (pitch level of “1” and pitch range of “5”?). However, looking at Matthew’s Music III paper, I see that pitch is specified in octaves, so that Middle C is 3.0. It looks very much like all of the 5 voices started with a mean of C1, C2, C3, C4 and C5. What isn’t completely clear is whether the center of the note varied, or if the bandwidth simply was controlled by the noise intensity alone. The intensity is certainly using the Music III CVT01 function, which used decibels. CVT01 = 10^P3/20.0, which means the amplitudes vary from 1.0 (0) to 501 (54).

In the instrument, there is a noise frequency and amplitude input, each of which can vary or remain constant. There is also the oscillator frequency input, which can also vary (by linear change) or remain constant. Tenney mentions that “for center frequency, the toss of a coin was used to determine whether the initial and final values for a given note were to be the same or different”. From listening to the piece, it seems that the other parameters (noise frequency and amplitude) were generated in a similar fashion.

 

analog #1 – noise study – rand, randx, randi – notes

I have been looking at James Tenney’s documentation for Analog #1 – Noise Study in “Computer Music Experiences 1961-1964.” I am hoping to recreate the instrument that Tenney used in this piece. As it was completed in 1961, the software he used was probably closer to Music III than it was to Music IV, though it seems he describes the instrument in Music IV terms.

In the “CME” document Tenney shows a unit generator (“U5″) called RANDI with two inlets, with the left controlling amplitude and the right controlling frequency or period. RANDI is a interpolating random number generator, that generates numbers at an audio rate. This is probably the same unit generator that is called RAND in Max Mathews’ article “An Acoustic Compiler for Music and Psychological Stimuli”. In Tenney’s 1963 article “Sound-Generation by means of a Digital Computer” he describes a RAND and a RANDX. RAND is the interpolating random generator, and RANDX holds the random value. In the “Music IV Programmer’s Manual”, the two functions are RANDI and RANDH (interpolation and hold).

There are two parameters for all of these unit generators. The left input is the limit of the random number generation or amplitude. The right inlet is described as a bandwidth control in the Music III document, where bandwidth = sample-rate/2 x right-inlet/512. If this inlet varies from 0 to 512, the bandwidth would vary from 0 to the nyquist rate. It is also described in the Music IV manual as a control of the rate of random number generation, where a new random number is generated every 512/right-inlet samples. This is pretty consistent through-out all of the documents, with one exception in Tenney’s 1963 article (figure 13) where he implies that the right inlet I controls period (period is 512/I).

So to emulate RAND/RANDI, I need to have two inlets – one which determines amplitude (I1), and the other which determines frequency (I2), where frequency is in a linear scale from 0 to 512, and 512 corresponds to a new random number generated every sample. Looking at James Tenney’s various example patches, with continuous envelopes sent into the inlets, it seems likely that floating point numbers were used for both of these inlets.

This untested code will generate a new random number that goes from i1 to -i1 every 512/i2 samples. This is what is implied by the Music III and IV documentation, but I can’t be sure of the method of random number generation. Also, like the originals, this is sample rate dependent. It will only act like the original code if run at a sample rate of 10,000 Hz.


 static t_int *randi_perform(t_int *w)
 {
 t_randi *x = (t_randi *)(w[1]);
 t_float *freq = (t_float *)(w[2]);
 t_float *out = (t_float *)(w[3]);
 int n = (int)(w[4]);
 int blocksize = n;
 int i, sample = 0;
 float phaseincrement;
 float findex;
 int iindex;
 while (n--)
 {
 // first we need to calculate the phase increment from the frequency
// and sample rate - this is the number of cycles per sample
 // freq = cyc/sec, sr = samp/sec, phaseinc = cyc/samp = freq/sr
if(*(freq+sample) != 0.0f)
 phaseincrement = *(freq+sample)/x->samplerate;
 else
 phaseincrement = x->x_f/x->samplerate;
 // now, increment the phase and make sure it doesn't go over 1.0
 x->phase += phaseincrement;
 while(x->phase >= 1.0f)
 {
 x->phase -= 1.0f;
 x->previous = x->current;
 x->current = random();
 x->current = (x->current/1073741824.0f) - 1.0f;
 }
while(x->phase < 0.0f)
 {
 x->phase += 1.0f;
 x->previous = x->current;
 x->current = random();
 x->current = (x->current/1073741824.0f) - 1.0f;
 }
*(out+sample) = x->previous + x->phase * (x->current - x->previous);
 sample++;
 }
 return (w+5);
 }

My next step is to build this into a PD external and test in a patch similar to what is used in Tenney’s “Noise Study”.

Update – 11/12/14

I have implemented the noise generator above, and have inserted it into a PD patch (I have edited the real code into this article). The results sound very much like Noise Study. Here is a single voice

Screen Shot 2014-11-12 at 12.42.10 PM

Now to determine the overall structure.