SoundPrism

In Ge's class we had to create an audio visualizer using OpenGL that shows the waveform, the spectrum, and some other feature of the audio.  I had never really written anything with OpenGL so this assignment presented an added challenge.  But after learning how the api works and getting my head around the geometry (which is vastly different from the 2D apis I've worked with [Quartz, GDI(+), Juce, AGG, VSTGUI]), I felt like a kid in a graphics programming candy store.  Also significant is that this is (surprisingly) the first time I've worked with FFT data in C++ code.  OpenGL makes it easy to create cool looking stuff, and I think that really rubs off on this program.  I've made a lot of use of it as a scope for my synths, but I'll definitely be using it as an instructional tool as well.

If you have a mac and want to try it out, it's at https://ccrma.stanford.edu/~adam/256a/hw3/

Quick Reflection, and some music

The MST has been keeping me extremely busy.  I can count on one hand the number of hours I spent relaxing last week.  Saturday I spent the entire day writing code for the next 256a assignment (a sound visualization application) and Sunday I spent most of the day doing DSP homework (working out DFTs by hand, proving theorems, analyzing spectral leakage).  Another project (for 250) was using data from the iPhone's accelerometer gathered over wifi to create some music.  I stayed up almost all night last Thursday working on a piece I call "Roil." Roil.m4a.  I've also been messing around with sensors (potentiometers, piezos, force sensing resistors, flex sensing resistors, accelerometers, photocells, and encoders [my favorite]) using the Arduino.  I've found 220a (intro to computer music) and 192a (recording technology) to be rather boring so far since I covered most of these topics in my undergrad, but these aren't particularly time-consuming so I'm glad to be solidifying my prior knowledge through repetition.  Also, 220 involves homework assignments using ChucK, which is forcing me to make use of that awesome language.

Deep Listening

It's tuesday 10/6, but this post is actually about last tuesday, when I was getting over a nasty cold and had a splitting headache.  Every morning in MUS220 we listen to each other's music for about 45 minutes.  Three people get to present their tunes each session, and I went last this time.  15 minutes is *almost* enough time for a single Sweat Shop Boys track, so I grabbed a copy of "440 Hurts" and folded it a little to make it fit.  I should get into the habit of listening deeply early in the morning, because lately I've noticed that my mind is much more sensitive and my body much more relaxed immediately after a shower, a cup o' joe, and a 2 mile bike ride.  Afterwards, Chris (the professor) said he could 'hear the whole class listening' to the music.  Indeed, there was a stillness in the room where usually people start to fidget after a few minutes of long, repetitive music.  He was inspired then to try one of Pauline Oliveros' sonic meditations, which had the whole class droning slow, steady, quiet pitches with our voices.  My headache magically vanished.

Zurich Institute for Computer Music and Sound Technology

There was 'pop colloquium' today at CCRMA.  The announcement was made just last night, so the audience was small and the duration short.  A handful of folks from the Zurich University of the Arts came by to talk about some research projects happening there now.  The one that especially caught my attention was Daniel Bisig's presentation on Interactive Swarm Orchestra and Immersive Swarm Spaces.  In brief (if I understand correctly), the studies map the results of lifelike swarm simulations (flocking birds, schooling fish, etc) to musical and graphical parameters.  The result is a transposition of the emergent properties of swarms (a single cloud like entity comprised of many individuals) to an artistic framework.  This kind of thing has interested me for a long time, in particular as a way to perform granular synthesis using something other than rand().  They have made C++ libraries available, which I think I'll be checking out some time soon.

Object-oriented audio systems

The first assignment for 256a (Music, Computing and Design I) was a doozie.  It involved creating a signal generator application with a handful of features like waveform selection and pulse width modulation.  My submission is here: http://ccrma.stanford.edu/~adam/courses/256a/hw1/

It didn't have to be a doozie, but once you get used to generic programming there's no going back, so I kind of went overboard.  The code can speak for itself; this post is about some issues that left me scratching my head a little.

The Flow of Callbacks

In my system I created a singleton entity that acts as a "Server," mediating the connections between audio processing objects (clients) and the DAC.  Clients can be registered with the server, and registered clients will get callbacks when the server gets its callback from the driver (the "driver" is a wrapper around some nice api like RtAudio, PortAudio, Juce, etc).  Clients connected to the dac can be processed and the their resulting outputs summed.  But what if clients are not connected to the dac, but connected to each other?  This is an obvious feature of modular audio environments (both analog and digital), but there is a  question of how best to represent these "connections" in software.  The way I decided to try was to design any classes that require input to hold a pointer to an abstract client.  Source objects can be registered with these, and their callbacks will be called by the client taking the input.  In this way, the callbacks "flow" in a depth-first traversal of loosely coupled clients in a graph, with the Server/DAC as the origin.  The question that remains is: is this optimal?  I've considered another way of dealing with processing, such as having the server process all objects, relying on a connection graph to handle dependencies (inputs to other clients).  I haven't really thought that one out, so maybe it's senseless.  But I'm not convinced at the obvious way I came up with is optimal.  And so I scratch my head...

Time


I ran into a bug when I connected a client to the dac more than once (for multi-channel output).  The bug was that the client would render new material more than once per buffer.  Ge explained to me that the notion of time is useful in determining whether a client should produce new audio or just return a copy of old material.  This hint was hugely insightful, and the problem went away.  However, now I'm scratching my head over the usage of the word time.  When the a client is asked for audio some time after it has already done so, it needs to know if time has advanced for the server, as well.  If not, then no new audio needs to be generated.  So in this sense, time is a perfectly good description of what needs to be considered.  But the word 'time' will inevitably come up again soon when I implement some kind of event scheduling system, and I know this has to be tied in to the server in much the same way.  The question now is should I create some kind of "time keeper" that manages time?  I need to draft some specs for the next phase of this project before I can know anything else...

Day 2

Music 220a

Fundamentals of Computer Generated Sound - Chris Chafe

According to the professor, 220a is a kind of programming course.  It is apparently designed to convey the basic techniques of digital sound synthesis and computer music composition, using ChucK as a pedagogical tool (a task for which I believe it is optimally suited).  The content of this course seems pretty straight-forward for me, but it's been three years since I've covered these topics in a classroom.  I'm looking forward to spending long nights curled up with a midi controller and my laptop, making bizarre bleeps and bloops into the night for academic credit.  One thing strikes me as odd, though.  The text for this course is Perry Cook's Real Sound Synthesis.  I actually read it this the summer, and it is rather in-depth, mostly focused on physical modeling.  Maybe there is more to this class than meets the eye.  We shall see.

The second half of the lecture took place in the Knoll Concert Hall, a room that is more reminiscent of a small chapel than a concert hall.  It sports 16 channels of ADAM speakers, eight around the walls and eight hung from the ceiling.  The presentation was a ~15 minute live computer music performance by Fernando Lopez-Lezcano.  The piece, entitled "A Very Fractal Cat" was played on a midi keyboard with foot pedals and switches.  The sound was like being inside a piano when someone sits down to play some atonal music, and all of a sudden the strings emit sonic smoke that wafts up as the extremely high partials decay.  Then the whole damn thing catches fire.  It was a good piece, but I wrote a note to myself during the performance: NO COMPUTER MUSIC BEFORE NOON!

Music 320

Introduction to Digital Audio Signal Processing - Jonathan Abel and David Berners

I guess this is the class I've been waiting for.  The signal processing series, taught by Abel/Berners or Julius O. Smith, represents my reason for being at CCRMA in the first place.  Today was really just a bunch of hand-waving over the field of signal processing.  Jon gave a very basic introduction to perception (cochlea, basilar membrane), digital audio signals, complex exponentials, sinusoids, and resynthesis.  Notwithstanding the elemental nature of today's lecture, during which I found myself installing Octave packages on my laptop, I learned something really important about dB conversion.

I had been confused by linear to dB conversions that sometimes involve 20*log something and sometimes 10*log something.  I guess I just wasn't looking closely enough.  Jon pointed out today that given a signal x(t), the dB representation of that signal is 10*log( abs( x(t) )^2) but is sometimes represented by 20*log( abs( x(t) ) ).  This follows from one the logarithmic identities, but I still wondered why one would choose to use one form over the other.  First of all, we need to look at why  the the dB system is the way it is.  In the first version of the dB calculation, the input signal is squared because the measurement is taken on the signal's power.  The power of two can be cancelled by the identity, and I suspect this form is desirable in computer systems because it removes the squaring operation from the computation.

Matriculation / Day 1

I'm officially a Stanford student and CCRMAlite.  You can check out the details of my coursework over at http://ccrma.stanford.edu/~adam.  Today was my second day of classes, and some first impressions are due.


First off, the Knoll (CCRMA headquarters) is a mansion dating to the 1910's and was once designated as the president's residence.  It feels rather like a castle, complete with stone construction, vaulted ceilings, and a spiral staircase.  The top floor offers views of San Francisco Bay to the north and the Stanford Dish / western foothills to the south.  It seems like the perfect place to watch the sun rise with a cup of strong coffee after an all night coding jam.


All of my six courses take place in the one classroom, room 217.  To get there you go past the music tech museum, up the spiral stairs, through a computer lab, and through another computer lab.  The room is furnished with long shared desks with AC outlets for all, and a projector shines onto the bare white wall at the front.  The walls are still adorned with old lamps and long drapes, and when chairs become scarce students sit in the windowsills or on the old radiator.  The room, perhaps the whole building, is reminiscent of J.F. Sebastian/J.R. Isidore's crib.  In short, it's a geek haven.


Music 250a
HCI Theory and Practice (AKA Physical Interaction Design for Music) - Edgar Berdahl & Wendy Ju


HCI Theory and Practice is a funny name for this course, as it is really about hardware hacking and home-made alternative musical interfaces.  The students in this course have to buy a kit which contains an Arduino and some sensors.  The thrust of the course is essentially to get us to learn a thing or two about electronics, embedded software, and using the two to control real-time audio processes running on a computer.  More specifically, the project involves the integration of sensors, arduino, firmware, and Max/MSP or PD.  I'm glad it's not a formal survey of HCI topics as presented in Computer Science, because I worked a little bit with an Arduino at CalArts, and I've been meaning to get back into that.


The course is taught by Ed Berdahl and Wendy Ju.  I had met Ed back in November 2008 when Miriam Kolar introduced me around.  He's very articulate and clearly enthusiastic about HCI for music.  He and Wendy presented some videos to get the gears turning, which can be found at http://ccrma.stanford.edu/courses/250a/videos.html.

Music 256a

Music, Computing, and Design I:
Software Design and Implementation for Computer Music - Ge Wang

Just to put it out there, Ge Wang is a bit of a celebrity in the computer music world.  Before I got to CCRMA, many people talked with had heard of him, or at knew of his projects.  It's no surprise, since he is the founder of the successful iPhone app company Smule, and he authored the ChucK programming language for real-time audio noodling/performing.  No doubt, his celebrity status is earned from his charismatic personality and open enthusiasm about new ideas, ranging from deeply intellectual issues to silly novelties.  Clearly, there are many fascinating sides to this man, and I'm thrilled to have someone this respectable as a professor (he's also my MST program advisor).

As for the course content, the first day was a lot of hand-waving about some really hefty issues.  For example, he was trying to briefly mention the follow-up course, 256b - Mobile Music, but ended up on a lengthy tangent about how handheld devices combine intimacy, communication, and creativity in a way that can change the way 

people think about making music, the way Beethoven changed the way people think about music.  He also touched on software design principles like polymorphism, a term which, combined with the requisite C/C++ experience, had to have scared away some newbies (hopefully).