Adumb's World

Some sexy shots

2010-03-14T16:26:00.000-07:00

TADA!

2010-03-14T00:11:00.000-08:00

It's done!

Man, this project took a lot of blood, sweat, and tears. I was sick all this week (after a grueling weekend of work on this), but luckily the only task at hand was to apply coats of varnish and wait for them to dry. Tonight I went in to the lab with the finished shell and put in the final 8 hours of cutting the sheet metal back plate, mounting the sensors, wiring the innards, and mounting the feet. I am pleased with the end result. What do you think?

The best part about today was that after I stuffed all the wires in the cavity and barely managed to secure the back plate, I found only two errors in the software that reads the sensors. So I opened her back up and quickly resolved the issue. Now I have a working controller. I say this to stress the importance of prototyping. If you ever want to build something of nontrivial complexity, prototyping is the only way to discover the 'essential' issues. Without that knowledge, you're dead in the water because, believe me, the 'emergent' issues will be laying in wait when you go to do the final build.

Progress

2010-03-07T23:58:00.000-08:00

A LOT of work has gone into the touchboard. From Thursday to Sunday I put in approximately 35 hours. The tasks that got done were: routing/drilling/filing/sanding/varnishing the padauk, re-wiring and heat-shrinking most of the sensor components, redesigning the circuit to accommodate more i/o than the Ardiuno has via a two 4051 multiplexer ICs, redesigning the Arduino firmware, and modifying the Max/MSP patch that receives the serial data from the Arduino. It was a weekend full of sawdust, solder, code, music, and beer. My favorite things :)

Padauk just after some drilling and routing

after first sanding

Component inventory

Comparison with prototype

2nd routing pass

Modeled with the lovely Michael Berger

with first coat of varnish applied

Building an instrument

2010-03-02T02:39:00.000-08:00

Building your own instruments is a lot of fun, and very rewarding. It is also a lot of work and an excellent learning experience.

I'm building a custom controller for myself as part of my 250b (HCI) project. The vision behind the project is to have a very solid and sturdy (think heavy) interface for delicate expressive interaction. The input is achieved with pressure and position sensitive strips mounted to the surface. These sensors will be covered with dense foam to increase the amount of physical travel. The motivation is to explore the effects of such materials as a form of haptic feedback for the performer. The device will also be equipped with a rotary encoder, six LEDs, and four buttons. In the future, it will be expanded with another pressure sensor (double the length of the others) and analog outputs for use with voltage controlled gear such as modular synthesizers. Here are some images of the work in progress.

Modifying an FSR strip

early experiments

First prototype

Second prototype, after getting handy with a router

Piece of Padauk to be used in final rendition

And here's Tom, the fine gentleman who patiently explained all I needed to know about buying hardwood and led me to that beauty of a block (and at a great price)

Fun Stuff!

2010-01-20T16:03:00.000-08:00

I was warned that Winter quarter would be extremely intense, and it is! I'm enrolled in several extensions or previous courses, namely 256b "Mobile Music" (iPhone programming), 220b "Compositional Algorithms, Spatial Processing, and Psychoacoustics", 192b "Advanced Sound Recording Technology", and 250b "HCI Design and Performance Systems for Music". I'm also taking my first course with the great Julius Orion Smith III AKA "King Nerd" AKA "The Janitor". The course is Music 420 "Signal Processing Models in Musical Acoustics". In other words, Physical Modeling. Julius is sort of the king of audio DSP. He writes, books, lots of books. I've read two of them (1, 2) for the intro to DSP course, and this course is based on this one.

The quarter is already well underway and we hit the ground running, with a rocket strapped our backs. So far I've created some music based on cellular automata, written three iPhone apps, designed a spherical midi controller (images soon to come), and learned a thing or two about physical modeling.

I suck at blogging

2010-01-05T21:42:00.000-08:00

Well, It's been forever since I updated the blog. I should have at least posted the "sorry for not posting" post some time ago. Anyway, it's irrelevant now (and who the heck other than me reads this, anyway?). So here's what I forgot to blog about:

- The augmented violin project. In 250A (Musical Interaction Design) each student had to submit a final project proposal. Mine would have been a spherical input device replete with encoders, sliders, LEDs, and an accelerometer. However, the final projects were done in groups, so not everyone's project was realized. The one I worked on was an augmented violin, which is a regular violin with electronic sensors added, plus some software to process the sensor data as "gestural input", plus some more software to sonify this gestural data.

- The Insaniac. The final project in 256A (Music, Computing, Desgin). This was a cross between a granular synthesizer and a kinematics simulation, all wrapped up in an aesthetically pleasant, animated, toy/instrument program. In other words, a glorified screen saver.

- The Mini-Instrument. A bunch of electronic sensors and LEDs mounted on a piece of foamboard and connected via perfboard to a breadboard with an arduino-based circuit on it. I played with this thing for hours as an input device to some software designed specifically for it. But I didn't record it! Now, the thing has been destroyed, the parts returning to the Max Lab aether. There is something extremely satisfying about creating something beautiful, not using it, and then destroying it. Ashes to ashes.

EDIT: It wasn't destroyed after all! Yay!

- The Music Programming Toolkit. AKA MusKit or MTK. Inspired by the Synthesis Toolkit (STK), I wanted to create a class library that can be used to develop music software. What does that mean, exactly? Well, it can mean many things. One the one hand we have STK, which leverages RtAudio and provides a suite of signal processing modules that can be used in any configuration the programmer might conjure. On the other hand we have Juce, a fully-featured cross-platform application development environment, complete with its own audio I/O, graphics engine, IPC, and even plug-in format wrappers. MusKit will fit somewhere in between these two environments. In other words, STK ⊂ MusKit ⊂ Juce. Muskit will provide all the hardware support and signal processing infrastructure as STK, plus a host of classes for connecting DSP modules in a musically meaningful manner (read: sequencing, timing, external control, etc), but it won't go so far as to dictate how your application should be structured. It will still be lightweight enough to easily integrate into a larger framework such as Juce, QT, Cocoa (via obj-c++), etc.

- The DSP final.

'nuff said.

- Lastly, I've applied to the CCRMA PhD program. As only two slots are open for it, odds are I won't get it. But not long into the MA program I realized a few things about myself and my goals:

I have a lot of respect for my professors, and I want to work with them as much as possible.
I am 5000% more productive than ever before. And I was never a slacker.
The work I am doing here is the best I've ever done, despite the short duration of each project.

How perfect would it be to have 4-5 more years to follow my pursuits? I would be able to take many classes (in fact, would be required to take at least 135 units), and work on a number of long-term projects.

Don't get me wrong, I want to have a company that makes great software and push the boundaries of what people have come to expect from music technology. But spending all this time at CCRMA, learning so many things, working on so many projects, I'm constantly reminded of one simple fact:

I don't know shit.

Great show last night

2009-11-13T12:41:00.000-08:00

Sweat Shop Boys played at CCRMA's fall concert, "A Cagian Music Circus", last night. The event lasted 1.5 hours, with performances happening simultaneously in six areas throughout the building. The free concert drew a crowd of about 150. Our performance took place in the CCRMA stage, a beautiful and intimate concert space (with no actual stage) designed for multichannel electroacoustic music. It's equipped with two rings of 8 ADAM studio monitors and four subwoofers for a grand total of 20 channels of 3-d playback. Sweatshop Boys are only used to playing on stereo rigs, bad ones, in acoustically bad spaces. So this was a welcome change, to say the least! We retooled our effects busses to output four discrete channels, which were diffused to the four corners of the space. Also new for us was a highly receptive crowd of like-minded people. The pic above is the only one I have at the moment, but many high quality pics should be available soon.

It's doesn't get nerdier than this...

2009-11-05T01:29:00.000-08:00

More info here https://ccrma.stanford.edu/~adam/256a/hw4/

SoundPrism

2009-10-30T13:19:00.000-07:00

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

2009-10-21T11:46:00.000-07:00

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

2009-10-06T10:38:00.000-07:00

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

2009-09-28T21:41:00.000-07:00

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

2009-09-28T21:15:00.000-07:00

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

2009-09-23T00:34:00.001-07:00

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

2009-09-23T00:33:00.000-07:00

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).

Don't Come Back

2009-09-17T22:13:00.000-07:00

I'm in La Quinta, CA where it's 93ºF at 9:45PM. There is a well-known historic resort here where Art & Logic is having their annual conference. This is my last day of work. Tonight at the final dinner by the waterfall the president of the company approached me by the dessert buffet and said, "don't come back."

Working for Art & Logic is pretty much a dream job. Developers work from home, share administrative and managerial duties, and are more or less treated like gods. The client list is long and attractive, we have a great reputation, and the presidents behave like doting fathers. I have never once experienced a moment when I felt that my common sense was being undermined. At times, clients have a tendency to stretch their expectations too far, but the management team at A&L are experts at handling these issues and the development teams are thusly insulated from stupidity (usually).

Many have asked why I am leaving such a cool job to return to school and incur an enormous debt while I clearly posses the wherewithal to have a successful career as a software engineer. The answer is simple: passion. I have a passion for audio technology and I want to make it the focus of my career. I have great ideas and I was to turn them into products. I am mystified by the rigorous mathematics in DSP, and need to understand it. That's exactly how Paul felt back in the dark ages. He told me he is jealous because I have the opportunity start at the beginning, to pursue my passion, and to never lose sight of why I got into engineering the first place. If he were to live vicariously through me, it would be his chance to do it all over.

So that's why he gave me some of the best advice I've ever received: "Don't come back."

Becoming a music technologist

2009-09-15T12:02:00.000-07:00

There are a lot of people out there who use music production tools for their art and dream of new ways to work, or have ideas for new sounds that they can only hear in their mind, or have thought of a revolutionary way to approach the process of sound synthesis, or sampling, or effects, or composition...

I am one of those people, and I have come to a point where I feel comfortable firing up a software project and putting pen to paper with a new idea. But I also know what areas of my knowledge need work, which is of course the most important question of all. I remember when I had no idea where to start. I remember how overwhelmed I felt when the idea of creating tools seemed unattainable. But by taking careful steps with the help of some fantastic people and a share of lucky breaks, I've acquired a set of skills that will help me as I continue the journey. So for anyone with similar interests I think I should explain a bit about what I do and how I got to this point.

What I do: I've been working as a programmer for just over three years. The first two were for Audio Impressions, where I developed some VST plug-ins and a big windows app called DVZ RT. It was a really cool experience and I learned a lot about how software is made. For the past year I've been working for a really cool software outsourcing company called Art & Logic. I found them when I first started looking for programming jobs, but decided to save that application for when I had more experience. Serendipitously, just after I left Audio Impressions to intensify my studies in Computer Science (more on that in a bit), Art & Logic found me! I primarily work on the Beat Thang drum machine, but have done some consulting on other projects related to music, audio, and other multimedia applications. Now I'm about to start the MST program at Stanford, and I'll probably be leaving Art & Logic to focus on that. I'd like to stay on-board to do a dash of consulting, but that is up to some higher-ups.

How I got to this point: It all started with a love of electronic music and a really bad attitude towards school. I was a crappy student in high school, especially in math, and my collegiate options were pretty limited. I only applied to schools with music tech programs (CalArts, U of Oregon, Berklee, Oberlin, U of Michigan, U of Miami). I was accepted to Michigan, Oregon, and Berklee. I went to Michigan. Looking back I think I should have gone to Oregon, because I hated Michigan. I hated the stuck up university attitudes, the arrogant professors, the cold weather, and the damned math requirement. So I reapplied to CalArts, which was close to my home town (Los Angeles), and they let me in. Problem solved, yay! Except for one thing....

CalArts, wonderful place. Full of diverse, interesting, and passionate artists who want nothing but to be able to make art. It's sorely lacking on the general education side, which shouldn't be a problem for most--in particular older undergraduates with prior education and of course grad students. For the average age college kid, however, it's a curse. Oh well. Problem for me was CalArts was where I got into engineering. I'm not exaggerating when I say that CalArts is the absolute worst place to take up engineering, except for the fact that you have plenty of free time to figure stuff out for yourself. And that's exactly what I did. I took a C programming class and then taught myself how to code in C++, create VST and Audio Unit plug-ins, make user interfaces, and a bunch of other stuff I became obsessed with. My teachers, in particular Miriam Kolar and Mark Trayle, my friends, in particular Cooper Baker and Tony Cantor, and the fine folks at the KvR Audio DSP and Plug-In development forum helped me immensely along the way. Constant hacking from late 2004 till I graduated in spring 2006 produced a portfolio that landed me the job at Audio Impressions.

Audio Impressions (AI) definitely took a risk in hiring me. They wanted someone with hands-on experience coding VST plug-ins, rather than a computer science graduate. And clearly they wanted someone cheap, but don't get me wrong, I was fine with that. Scoring that job was pure elation. I owe it all to Stan Bartilson, the "chief software architect", who had decades of experience but nonetheless offered me the chance to prove that a dedicated hacker can learn to do anything, as long as the focus and passion is there.

As it turns out, I'm not so sure that wanting it is really all it takes to be a great software engineer. There's a reason why there is a branch of academia called Computer Science, which is separate and distinct from the Computer Programming. The latter relies heavily on knowledge of the former, and, as with any science, the academic environment is best suited to learning. Not to say that it can't all be picked up in the field, but as soon as I had to have conversations about optimal data structures, search and sort algorithms, and assembly language programming, I pretty much immediately enrolled in computer science and math courses and split my time between work and school.

And so, the crappy student who avoided math like the plague got into engineering at an art school and wound up voluntarily enrolling himself in math courses. LOTS of math courses. I picked ones that seemed to be essential to DSP and computer science:

Pre-Calculus
Differential Calculus
Multivariable Calculus
Linear Algebra
Discrete Math

And as for computer science, I figured I should take all the necessary courses needed to fulfill the breadth requirement for application to UCLA's C.S. Master's Degree

Computer Architecture
Data Structures and Algorithms
Computer Organization
Programming Languages
Operating Systems
Formal Languages and Automata Theory
Software Engineering

As you can see, I loved this stuff, at least enough to split my income in half for 2.5 years to pursue it. I found my calling. I was going to get a masters in Computer Science. Then I looked in to the fields of study within computer science: Human Computer Interaction, Computer Vision, Artificial Intelligence, Security, Databases, Networking, Theory. And you know what? None of that had anything to do with music or audio. I could have made my way through one of those areas and applied it to music technology, but in the end I would have ended up going down a much more travelled path. And if you ask me that's boring!

As far as I know, the MST program at Stanford is the only music technology program that provides the theoretical rigor I am craving, as I already have the fundamental background and engineering prowess, and I'm not looking to make art in an academic setting. So it was the only program I applied to. I'm in, I'm thrilled, and classes start in 6 days!

1st post hahaha!!11!!one!!1!eleven

2009-09-15T10:35:00.000-07:00

I've decided to create a web log to chronicle my studies as an MST student at Stanford's Center for Computer Research in Music and Acoustics (CCRMA [pronounced 'karma']). This is mostly for my own use. It's a way to enhance my learning by trying to explain some of the mind-boggling stuff I'm about to study. I'll also add other interesting tidbits relating to programming, digital signal processing (DSP), and other music technology related findings.