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: pbat.ch/wiki/audio_programming

@paul

> 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"
@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.
Follow

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

· · Web · 1 · 0 · 0
@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.
Sign in to participate in the conversation
post.lurk.org

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