Finally got around to writing down some audio programming tips for the musically inclined trying to learn, based on my own personal experiences and struggles learning how to do it myself:

· · Web · 2 · 7 · 8


Code is a terrible way to learn DSP.

Audio programming is mostly math.

Most programming languages aren't suitable for audio DSP.

Offline first, then real-time.

Avoid plugins for a while.

Avoid FAUST for a while.


> Code is a terrible way to learn DSP

yeh this has given me problems with code in general. optimized code is difficult to glean much out of. especially since its extremely non-obvious how they got from "i need a low pass gate" to "so here's this SIMD operation with a 4-variable biquad approximation"

@icedquinn yup. getting into that kind of stuff is just not what most people signed up for.

@paul i've wondered if a notebook interface would be a better way to deal with high performance code. the theory here is that optimizers run on passes but they tend to use a fixed set and you have to play footsies to see when GCC does or doesn't make your shit work better. so instead, start with writing in a DSL and then show (in the notebook) running each optimization step and the result, kind of like those compiler explorers, except the notebook stays around as the actual source file.

when i poked around with Nile (a reasonably complete canvas library in <1,000 SLOC) that was close to they did; they just wrote stream processing kernels and a mini-compiler turned it in to C/JS with all the boilerplate crammed on.

@icedquinn I mean, at some level I suppose. But for me that just sounds like more brittle layers of complexity. The thing is, software doesn't actually seem to work most of the time. I tend to want less of it, not more of it.

@paul what ends up happening otherwise is the human just writes code the black box compiler does stuff to, has to try and disassemble to see what it actually did, and then changes the code going in to something that isn't like it originally was, and the record of how you got from this simple biquad to AVX instructions is lost forever.
@paul unrelatedly have you played with the axoloti patcher? it's interesting. presents as a puredata/max style graph but its actually just a faceplate for simple C functions. each "object" is defined in some state variables, one or two rate functions, and then the patcher exposes this as a set of blocks to be strung together.

@icedquinn I've not used it myself, but I've definitely seen stuff like it. Enzien audio made heavy, which was open sourced and abandoned when the company tanked. That converted PD patches to code. STM had a proprietary patcher thing for their boards. The teensy audio board has a rather rudimentary patching web interface I think? I also remember seeing some random hardware startup at SXSW a few years ago doing that as well.

Is the axolotl patcher thingy open source?

@paul axoloti patcher is open source (java), the modules are MIT or GPL, and the board spec is open (but not the gerbers, because he doesn't want zero-effort clones)

low key looked at routing a board because its almost impossible to get them right now.
> zig

eh not a fan of zig. lack of operator overloads is pants.

i do enjoy nim, which compiles to c, largely in part because its very pliant and straightforward. you can easily do something like `type CV* = distinct float` and now you have what is basically a float and does all the float things but the compiler will :blobcatpolice: if you try to accidentally put the control voltage in something else without coercing it.

@icedquinn I don't really miss operator overloads for audio programming. I do for graphics though.

From what I can tell, Nim seems suitable for realtime, sometimes. Maybe things have changed, but don't you have to pass some extra options to get it to work?

@paul -gc:arc if you don't have cyclic references, -gc:orc if you do, replaces the GC with reference counters.
@paul there is newruntime which is supposed to have introduced uniqueptr semantics. araq wanted to migrate over to it but they chose to stabilize 1.0 before messing around with deep runtime shit again
Sign in to participate in the conversation

Welcome to, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.

<svg xmlns="" id="hometownlogo" x="0px" y="0px" viewBox="25 40 50 20" width="100%" height="100%"><g><path d="M55.9,53.9H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,53.9,55.9,53.9z"/><path d="M55.9,58.2H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,58.2,55.9,58.2z"/><path d="M55.9,62.6H35.3c-0.7,0-1.3,0.6-1.3,1.3s0.6,1.3,1.3,1.3h20.6c0.7,0,1.3-0.6,1.3-1.3S56.6,62.6,55.9,62.6z"/><path d="M64.8,53.9c-0.7,0-1.3,0.6-1.3,1.3v8.8c0,0.7,0.6,1.3,1.3,1.3s1.3-0.6,1.3-1.3v-8.8C66,54.4,65.4,53.9,64.8,53.9z"/><path d="M60.4,53.9c-0.7,0-1.3,0.6-1.3,1.3v8.8c0,0.7,0.6,1.3,1.3,1.3s1.3-0.6,1.3-1.3v-8.8C61.6,54.4,61.1,53.9,60.4,53.9z"/><path d="M63.7,48.3c1.3-0.7,2-2.5,2-5.6c0-3.6-0.9-7.8-3.3-7.8s-3.3,4.2-3.3,7.8c0,3.1,0.7,4.9,2,5.6v2.4c0,0.7,0.6,1.3,1.3,1.3 s1.3-0.6,1.3-1.3V48.3z M62.4,37.8c0.4,0.8,0.8,2.5,0.8,4.9c0,2.5-0.5,3.4-0.8,3.4s-0.8-0.9-0.8-3.4C61.7,40.3,62.1,38.6,62.4,37.8 z"/><path d="M57,42.7c0-0.1-0.1-0.1-0.1-0.2l-3.2-4.1c-0.2-0.3-0.6-0.5-1-0.5h-1.6v-1.9c0-0.7-0.6-1.3-1.3-1.3s-1.3,0.6-1.3,1.3V38 h-3.9h-1.1h-5.2c-0.4,0-0.7,0.2-1,0.5l-3.2,4.1c0,0.1-0.1,0.1-0.1,0.2c0,0-0.1,0.1-0.1,0.1C34,43,34,43.2,34,43.3v7.4 c0,0.7,0.6,1.3,1.3,1.3h5.2h7.4h8c0.7,0,1.3-0.6,1.3-1.3v-7.4c0-0.2,0-0.3-0.1-0.4C57,42.8,57,42.8,57,42.7z M41.7,49.5h-5.2v-4.9 h10.2v4.9H41.7z M48.5,42.1l-1.2-1.6h4.8l1.2,1.6H48.5z M44.1,40.5l1.2,1.6h-7.5l1.2-1.6H44.1z M49.2,44.6h5.5v4.9h-5.5V44.6z"/></g></svg>