I had a bit of a tumultuous landing in New Orleans. Several distinct episodes spanning a few months each, with some real I-should-write-a-book material here and there. This place is wild.

Lately I’m on my feet, pushing code to github every few days, playing music around town, and generally getting back in the groove of things. Say, here’s a blog post!

When it comes to writing effects and live coding, I began to favor pure SuperCollider this past year. Overtone is awesome, and I can’t remember what made me drift away from it, but I’ve found that the JITLib extension to SC does everything for me that Overtone did, as well as solving a couple problems with my use-case of mostly live-coding effects (as opposed to patterns and synths).

I’m still intrigued by live-coding music in Clojure. It’s likely that I will reintegrate Overtone into my toolkit soon, but right now the rough prototype I’m performing with is pure SC. Regular rehearsals and performances will teach me what I need, and I’ll probably use Overtone to build it where it makes sense.

I’ve performed with SuperCollider in New Orleans a couple times now, and I’m actively collaborating with some local musicians on a weird psychedelic free jazz type deal. We’re having an absolute blast, and I look forward to being able to share some of what we make.

I wrote a small Android app this past winter before taking a break to tend to some work for a client and then chase more work. I’m excited about that.

After this, expect some posts on various nuances around writing delays and other FX in SuperCollider.

I haven’t posted since February, and feel I should explain such a long drop-off after such an enthusiastic post.

I’ve continued my work in my typical ADD fashion. I’ve got a number of things in the air. I’m writing a couple Android apps, have continued work on the Overtone stuff (and played a bit with Sonic Pi), and have continued to flip through the DSP book (more exercises coming soon). But the principle reason I haven’t updated in awhile is that I have moved from Seattle, WA to New Orleans, LA to switch my primary focus from computer work to musician. The process of planning and executing such a big move soaked up several months, and I didn’t do it without considerable help from friends and family.

Regarding my change of focus: I’m chasing a couple remote software dev jobs right now, so it’s not like I’m dropping out of the industry (I did consider it, but I should keep my tech career at least on life support — I worked pretty hard to break in, and too much disillusionment is a little bratty of me).

If you read this (which would surprise me if you’re anybody other than me and my mother), expect more DSP geekery and clojure shenanigans in coming months, as well as more posts around music and even a little politics. This is primarily a professional space, but I deleted all my social media about 5 months ago and have found myself writing a lot more. I haven’t decided whether to start a separate blog or to just tag posts on this one. Either way, I’m not renting my prose out to a large data-harvesting corporation.

Till then.

My solution to “homework” question 1.1 in Richard Lyons’ Understanding Digital Signal Processing:

\pi \approx 4 * \sum\limits_{n=0}^{100} (-1)^n * \sum\limits_{m=0}^{100} 1/(2m-1)

To complete this problem, I had to do some extra reading on sigma notation, as well as discover some nifty little formulas (inspired by the tricks mentioned in that second link about Partial Sums). For example I did not know off the top of my head that powers of negative one alternate between positive and negative (though that’s intuitive now that I know and can think about it). The equation didn’t make much sense to me until I discovered this fact while playing with code.

Aside from reading up on the formal math syntax, I wrote a little throw-away Python and Clojure code to mess around with the algorithm and make sure I didn’t get any way-off-base ideas about the math. I started with some list comprehensions in a Python shell and once I had understood some things I switched to Clojure. At one point I got approximate pi with:

(* 4.0
     (reduce + (map #(/ 1.0  %) (map #(- (* 4 %) 3) (range 1 9999999))))
     (reduce + (map #(/ -1.0  %) (map #(- (* 4 %) 1) (range 1 9999999))))

This works by finding alternating odd numbers with 4n-3 and 4n-1. I found that trick on Stack Exchange. It was shortly after writing this code that I found the powers of one trick and suddenly the original problem made sense to me.

I’m finding Rich Lyons’ book to be the perfect level of detail; there are just enough breadcrumbs for me to piece together what I remember from high school to inform my web searches to explore the subject. It’s a little slow going, kind of like how I remember my first forays into computing. As I get this basic math theory internalized I’ll bet things will speed up dramatically, just as they did when I got enough contextual knowledge around telling computers what to do. The principles of DSP don’t look too hard to grasp conceptually; the hard part of truly learning anything is walking through it until it’s solid. So here’s me doing that.

Formal math is just another programming language. I will learn it, and then it will teach me things. I’m very excited about this. It’s also deeply gratifying to be teaching myself the formal mathematics armed with years of experience coding. Being able to test my assumptions as I go by translating the formal math into code representing how I understand it is an extremely powerful learning tool.

My mother works as an IT consultant in the Bay Area (it’s a pretty rad story, she taught me my computing fundamentals as a kid but could never break into the industry due to its biases and such, until ten years ago after my folks relocated to the Bay Area during a tumultuous time for all of us. I stayed in Seattle and broke into tech a few years later).

She just handed-me-down a glorious Dell XPS 13, which I immediately installed my standard Arch Linux + Awesome WM dev environment on.

Hmm. Beautiful screen, but I can’t see anything. I squinted through the Arch install process, but when I got my window manager and favorite dev tools up-and-running, something needed to be done.

Now, it turns out that I really didn’t need to do this and it was just a fun exercise: https://wiki.archlinux.org/index.php/HiDPI


This code scales the workspace and window decorations — I need to write a similar function for the menus. It assumes that a theme’s font will be stored in a variable theme.font in the format “fontname 7”, which is what I found to be the case in the Arch theme. I didn’t do any other checking or testing. Without further ado, here’s what I added to my ~/.config/rc.lua:

local theme_name = "arch"

local function scale_theme_font()
  local theme = awful.util.get_themes_dir() .. theme_name .. "/theme.lua"
  local theme_config = gears.protected_call(dofile, theme)
  local fs_start, fs_end = string.find(theme_config.font, "%d+$")
  local scaled_fontsize = tonumber(string.sub(theme_config.font, fs_start, fs_end)) + 5
  local scaled_font = string.sub(theme_config.font, 0, (fs_start-1)) .. tostring(scaled_fontsize)
  theme_config.font = scaled_font
  return theme_config

local theme = scale_theme_font()

The harmonizer needs a little tuning, I’ll be playing around with the parameters of the ugens. But it sounds pretty decent as long as you’re within a certain range, and if you push it you can generate some pretty fun-sounding artifacts. Try beatboxing into it while humming your bassline.

I’ve hard-coded the bus my microphone is on, so you’ll need to edit that if you wanna paste this code into your REPL or your cider-connected emacs/vim. But anyway, here’s this:


(definst voice1 []
  (sound-in:ar 1)

(definst harmonize-input
  [note 60 velocity 80 gate 1 bus 1]
  (let [in (sound-in bus)
        pitch (pitch:kr in 
                        :exec-freq 500 
                        :down-sample 0.1)
        amp (/ velocity 127)
        env (env-gen (adsr 0.01 0.1 1 0.3) gate :action FREE)
        orig-midinote (cpsmidi pitch)
        interval (- note orig-midinote)
        ratio (midiratio interval)
        sig (pitch-shift:ar in :pitch-ratio ratio)
      (* env (* amp [sig sig]))
(def harmonizer 
  (midi-poly-player harmonize-input 
                       (first (midi-connected-devices))) 
                     :none ))


I’ve translated tutorial 4! That was several months longer than I intended to wait. There were extenuating circumstances.

My Clojure skills, as well as my understanding of both SuperCollider and Overtone, have improved dramatically since I tried translating Tutorial 3. This only took me an afternoon, and everything worked as expected.

The only thing I got stuck on for a couple hours is triggered params. In SCLang, you can prepend a ‘t_’ to a parameter name on the synth-form function (the second argument to SynthDef) and it will automatically create a triggered control Ugen. Overtone does not do this, and from a design perspective I think that’s a good call. But how on earth do I get, say, a gate to automatically revert to 0 after I set it to something else?

I went reading source code, but all I really needed to do was re-read the doc string for Overtone’s defsynth.


Params can also be given rates. By default, they are :kr, 
however another rate can be specified by using either a 
pair of [default rate] or a map with keys :default and rate:

(defsynth foo [freq [440 :kr] gate [0 :tr]] ...)
(defsynth foo [freq {:default 440 :rate :kr}] ...)

Anyway, all you have to do to get a TrigControl instead of a Control Ugen is to set the parameter’s rate to :tr using either syntax demonstrated above. See also: http://doc.sccode.org/Classes/SynthDef.html

I’m really loving Overtone. Once I really started to understand how SuperCollider works, I found that Overtone is usually pretty faithful to its design. You just write the same thing in Clojure. Sometimes there are small differences like the one above, but they’re typically improvements and they’re documented.

My code is here.

I can’t wait to get to buffers. Yeehaw.

More soon!

Being a musician is what brought me to computing in the first place. I tell prospective employers and clients ‘computing is my other guitar’ and it goes over well. It also happens to be true. Within 5 years I see myself working in pro audio, or perhaps writing some sonar computer vision type wizardry. Of course, I’ll also be making and performing music on a regular basis for the rest of my life.

So my interest brought me to SuperCollider and the like, but I lack classical math training. I dropped out of high school and didn’t even develop serious tech skills until I was 22 or so.

The concepts of DSP are implicit in working with SuperCollider and making music in general. Though I have long felt I needed a more explicit understanding, at the same time I felt daunted about teaching myself math as it relates to DSP the same way I’ve taught myself to code. I dunno what my block was, but I’d always lose momentum. Perhaps I wasn’t driven by the same obsessive curiosity. I have glossed over and understood it conceptually, but if I’m gonna do the kind of work I want to end up doing I’m going to need to walk through the concepts step-by-step and internalize them.

At a Clojure meetup recently, I mentioned my interest in DSP and lamented that I was gonna have to figure out some way to get to school in order to get the math I need. A fellow attendee said “Oh you can teach yourself that too.”  and told me to read the book ‘Understanding Digital Signal Processing’ by Richard Lyons. He told me it lays out all the math concepts you need and it’s very easy to digest without a prior background.

So far I have found that to be true, and I’ve got the momentum I’ve been searching for. In addition to taking notes, I’m gonna write code that demonstrates to myself the ideas being presented.

I’ve published my first such exercise on github:


At the end of September I lost my big sister, and although I have continued work on my Supercollider, Clojure, and other projects, I’ve done a terrible job of documenting it. I retreated back to Seattle from the Bay Area to mope among friends. I could say a lot on this subject, but this blog is intended to be more of an account of my professional and hobby work than a personal writing space. Suffice it to say that I had a bit of trouble functioning for most of October and November and had to change the timelines on my plans both personal and professional. I’ve played a lot of music and spent most of my time on friends’ couches. I am starting to get my wind back; hence this post.

I didn’t end up completing the work of translating SuperCollider tutorials into Overtone yet, though I will. My chops are up to the point where I could do it in a few days’ coding (I have stayed busy). But there seems to be a bug in how the Ugens get compiled and sent to the SC server. I haven’t done the legwork of verifying it (which could turn into the legwork of fixing it), but I intend to get to that soon as well. *EDIT* there’s no such bug. I was making several different kinds of mistakes in my early attempts at translating SC code into Overtone.

I was just really excited to make some noise, so I instead pored over the Overtone code until I could figure out how to instantiate nodes for synthdefs already loaded on the server, and still take advantage of Overtone’s studio system with all the groups, the mixer synth, the FX chain and other conveniences. Thus, I’m currently writing all my effects and synths in SuperCollider and just controlling everything from Overtone. It’s a hack, but at the time it was the path of least resistance and allowed me to continue to develop my skills.

So I got some code written and a rig built up to the point where I could take it to a jam session and get sound in one end and out the other with a couple simple effects. Having achieved that milestone, I’m currently in a long grind of just building up a library of nifty effects and synth tones. In addition I have begun an earnest study of DSP, am making music with Renoise and some VST plugins (just to get used to designing synths without simultaneously thinking about code, though I will mess around with using SuperCollider synthdefs as well), and showing up at jam sessions with my guitar and trumpet.

I’m going to start with the rig as my personal effects rig for the trumpet. But where before I was chasing it obsessively, I’m currently letting the project breathe a little. A band/project has formed around all this with a skilled drummer and his music-producer brother, but I’ll let that project speak for itself as it develops (I mention it here because it accounts for my more relaxed pace on the technical side of things — there’s writing and rehearsing afoot).

Around October it started to become especially urgent that I find work, so that’s divided my attention a little. In that pursuit I have:

  • written a toy in Clojure to mess around with large XML data sources, teaching myself how to use transducers in the process.
  • worked on a couple of Rails projects
  • wrote a Python script that fingerprints the website of all businesses retrieved from the Google Places API looking for issues I can call them about.
  • written a Luminus-based webapp with Vue.js on the frontend to track my contacts with these prospects
  • intermittently panicked

I think that more-or-less covers everything I’ve been up to that I’d like to share. As always, expect more soon, but for real this time.

As part of a project that has been torturing me with its lack of existence since 2013, I need to learn Supercollider and Overtone. This is what brought me to Clojure in the first place. I’ll be blogging about that project plenty, but enough of that for now.

So I’ve been translating Supercollider code from Eli Fieldsteel‘s very excellent YouTube Supercollider tutorial series into Clojure for use with Overtone. It’s the domain-specific knowledge that gets you. I can’t be productive in Overtone until I understand how Supercollider works. So I’ve got to start with Supercollider, but keep my chops up in Clojure. Hence, this exercise.

Tutorial 3 talks about composing Ugens together to define and control synths in Supercollider. Yesterday and today I translated the final pulseTest synth into Clojure. What I’ve got sounds almost like the example code run from the Supercollider IDE, but something’s off with the ampHz Ugen. It seems to be pulsing at about half the speed, and occasionally I get a very loud low-frequency boom when I kick off the synth. I’d appreciate anyone who can spot my error or help me track down the cause. Here’s what I have:

(defsynth pulsetest "A super awesome synth that almost works the same as it would in SC"
  [ampHz 4
   fund 40
   maxPartial 4
   width 0.5]

  (let [amp1 (* 0.75 (lf-pulse:kr ampHz 0   0.12))
        amp2 (* 0.75 (lf-pulse:kr ampHz 0.5 0.12))

        freq1 (round 
                ; http://doc.sccode.org/Classes/UGen.html#-exprange explains
                ; that it uses a LinExp ugen to do the work. Here, we do the
                ; same manually 
                (lin-exp:kr :in    (lf-noise0:kr 4) 
                            :dstlo fund 
                            :dsthi (* fund maxPartial)) fund)
        freq2 (round 
                ; see above
                (lin-exp:kr :in    (lf-noise0:kr 4) 
                            :dstlo fund 
                            :dsthi (* fund maxPartial)) fund)

        freq1 (* (+ 1 (lf-pulse:kr 8)) freq1)
        freq2 (* (+ 1 (lf-pulse:kr 6)) freq2)

        sig1  (* amp1 (pulse:ar freq1 width))
        sig2  (* amp1 (pulse:ar freq2 width))

        sig1  (free-verb:ar sig1 0.7 0.8 0.25)
        sig2  (free-verb:ar sig2 0.7 0.8 0.25)]
      (out 0 sig1)
      (out 1 sig2))

Here is the SC version:


SynthDef.new(\pulseTest, {
        arg ampHz=4, fund=40, maxPartial=4, width=0.5;
        var amp1, amp2, sig1, sig2, freq1, freq2;
        amp1 = LFPulse.kr(ampHz,0,0.12) * 0.75;
        amp2 = LFPulse.kr(ampHz,0.5,0.12) * 0.75;
        freq1 = LFNoise0.kr(4).exprange(fund, fund * maxPartial).round(fund);
        freq2 = LFNoise0.kr(4).exprange(fund, fund * maxPartial).round(fund);
        freq1 = freq1 * (LFPulse.kr(8)+1);
        freq2 = freq2 * (LFPulse.kr(6)+1);
        sig1 = Pulse.ar(freq1, width, amp1);
        sig2 = Pulse.ar(freq2, width, amp2);
        sig1 = FreeVerb.ar(sig1, 0.7, 0.8, 0.25);
        sig2 = FreeVerb.ar(sig2, 0.7, 0.8, 0.25);
        Out.ar(0, sig1);
        Out.ar(1, sig2);


And that’s how far I am. I’m going to proceed to another tutorial for now. I’m also going to find a theme and plugin that makes this code look a little nicer.

You can track my progress at the git repo I have set up for this project.

I was about to write another post about my journey with Supercollider and Overtone, and I probably will right after this, but I had a thought about learning to code that I thought merited its own post.

Learning the syntax and semantics of a programming language, especially a modern one like Ruby, is indeed achievable within the context of a bootcamp. But the real challenge of programming isn’t learning how to talk to computers. It’s learning how computers talk to each other (roughly layers 3-6), how programs talk to each other (layer 7 when it comes to network, plus a bunch of other concepts and markup languages and, as you get more advanced, OS-specific API knowledge), and the general ecosystem in which your programs live (sysadmin/tech support background helps here).

There’s a blog post that pretty accurately captures all the extra stuff you pick up as a web developer, but it tries to sell you more bootcamps and classes. I can’t vouch for the content of those classes, but I can tell you from experience that this isn’t a problem you have to throw money at. Linux is free and will run on equipment you would have retired.

This “extraneous” knowledge amounts to several years of active computing experience. You just have to spend a couple years messing around with computers, trying to run Arch and get everything done, stopping to troubleshoot esoteric problems, etc. Somebody with an IP address in China logs in and deletes your home directory for lulz. You grieve the years’ loss of writing, recordings, and other personal data. You learn iptables, set up denyhosts, start using SSH keys, change the way you structure your network, and start backing up your data (ask me how I know!).

Or you can take some classes, I suppose. I chose the former route.

Either way, as far as I can tell, there’s no shortcut. Until you get this contextual knowledge, you’re gonna struggle. You know a language, but have nothing to talk about for lack of any frame of reference. It’s like learning the words in Spanish for “fruit”, “dress”, and “bathroom” but being from an alien planet where they don’t eat, wear clothing, or defecate.

I think the main problem with a lot of these training courses, and the culture of learning to code, is that they gloss over this part of the journey. People get frustrated, conclude that they’re just not smart enough for the craft, and give up.

I think that’s the wrong conclusion. You just have to realize that on your way to true competence, you’re gonna have to take on some pretty massive side quests as part of the grind. You probably have what it takes. This is just a very long game.

And when you’ve mastered the “basics”, there’s a whole other level to get at. For a professional software developer, it should be a given that they know their network, they know how OS’s work, they know how various flat-file and database storage systems work, they know a couple markup languages and a couple Layer 7 protocols, and a ton of other miscellaneous stuff I’m forgetting. Taking all that stuff as a given, here’s my frontier.

Keep learning. We practice a deep craft.