Csound: A sound and music computing system

I appreciate that the title of this post calls it a "sound and music computing system" rather than a "musical programming language". In truth, Csound is more of a text-based modular synthesis environment than a programming language.

As others have said, the orchestra syntax is a bit strange at first, but you do get used to it. Writing Csound code feels more like patching a modular synthesizer rather than writing a computer program. It's basically a DSL for connecting small sound/signal modules (called opcodes) together. Most of the time one thinks about things in terms of signal flow and not computer logic. A common mistake I see new Csounders make is to immediately reach for the conditional statements and loops. They often don't behave the way you expect, so people get frustrated.

The Csound dev team has a very strong emphasis on backwards compatibility, to the point where the older opcodes do not get bugfixes in case someone is exploiting the bug in the compositions. The programmer in me groans a little bit, but the composer takes great comfort in the fact that pieces I write now will be playable for many years or even decades (some of the Csound test pieces, like Trapped In Convert by Richard Boulanger or Xanadu by Joeseph Kung, are over 30 years old and still run).

I've been told that many works written in MusicN languages (a precursor to Csound) have been ported to run in Csound, which means that the legacy of Csound includes computer music written in the 60s! I wish I knew where to find those, as I quite enjoy computer music history.

As a resident of both Davis and Berkeley, CA I've heard a lot of stiff academic music made in Max/MSP on UC campuses, though I'd say UC Davis' Bob Ostertag is the notable exception - really compelling stuff - but that's because he's using at as an expressive musical instrument.

But still, these environments hopefully provide a DSL/interace that abstracts away some of the complexity of bare-metal C or C++ code; and non-PhDs like Autechre, Squarepusher, Aphex Twin, BT, Leafcutter John and Christopher Willits have made great-sounding things with them. And these tools are often used by professional audio developers to quickly prototype DSP algorithms.

You can make midi interfaces in Python and plugins in LADSPA and other things with Jack ... lots of programs are fairly extensible these days.

so for instance, instead of a physical instrument connected to a usb port, your software is feeding the midi input into some other software, say something simple like seq42 (https://github.com/Stazed/seq42)

Synthesizers have some interesting things too. https://zynaddsubfx.sourceforge.io/ uses an XML format for its synthesis definition. It also has "learnable midi" as in parts of the interface can be instrumented from a midi controller - so you turn a knob in physical space and it turns in the software accordingly.

So let's go back to the previous part, the part about software defined midi. You can now emit the mutation of the sound and the sound itself into software like that. Here's a 2005 linux journal article with a screen shot (https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...) essentially the stack I just said. https://www.linuxjournal.com/article/8304 ... "2005" you say? yeah, old pianos also still work.

The linux space is littered with generic audio tools that don't really work on their own and must be pasted together with other tools in order to get anywhere, much like in the shell. I did a bit of editing on the linux audio wiki about 3 years ago, it's probably the best place to look: https://wiki.linuxaudio.org/wiki/introduction

It's still just a bunch of hacks on top of hacks. Things break all over the place and latency is a bitch ... I dunno, there's a lot out there.

wondering if you have any favorites that you can recommend.