#csound

There are some things I definitely do not like about the Csound code, mainly the cryptic names, and the use of preprocessor macros. Aside from that, here are a few of the good things in Barry’s code:

Of course the big home run was writing Csound in platform-neutral C, still the most performant programming language, and still available on more platforms than any other.

The extreme simplicity and efficiency of the inner loop for running Csound performances.

Invisible, automatic handling of multiple notes playing at the same time, for the same instrument.

The extremely flexible design for unit generators (opcodes), the building blocks of sound synthesis. Essentially, although written in C, Barry’s unit generators are classes -- data structures that derive from a virtual base class, and include methods for operating on their own data. The virtual base class idea makes it quite easy to extend Csound with new unit generators, and now even plugin unit generators.

The musical power and flexibility of Csound’s score language, which permits the user to define any set of fields for an event; and these fields are not limited to integer values, but are real numbers. Furthermore, based on his experience as a composer, Barry made sure his score language could handle tied notes, polyphony, changes of tempo, and so on. This is far more powerful than MIDI.

The policy of complete backwards compatibility. The very first examples and compositions still run on today's Csound!

I also discovered that some popular digital audio workstations (DAWs), the workhorses of the popular music production industry, can embed algorithmic composition code written in a scripting language. For example, Reaper can host scripts written in Lua or Python, both of which are entirely capable of sophisticated algorithmic composition, and both of which have Csound APIs. And of course any of these DAWs can host Csound in the form of a Cabbage plugin.

All of this raises for me the question: What's the playpen? What's the most productive environment for me to compose in? Is it a DAW that now embeds my algorithms and my Csound instruments, or is it just code?

Right now the answer is not simply code, but specifically HTML5 code. And here is my experience and my reasons for not jumping to a DAW.

I don't want my pieces to break. I want my pieces to run in 20 years (assuming I am still around) just as they run today. Both HTML5 and Csound are "versionless" in the sense that they intend, and mostly succeed, in preserving complete backwards compatibility. There are Csound pieces from before 1990 that run just fine today -- that's over 33 years. But DAWs, so far, don't have such a good record in this department. I think many people find they have to keep porting older pieces to keep then running in newer software.

I'm always using a lot of resources, a lot of software, a lot of libraries. The HTML5 environment just makes this a great deal easier. Any piece of software that either is written in JavaScript or WebAssembly, or provides a JavaScript interface, can be used in a piece with a little but of JavaScript glue code. That includes Csound itself, my algorithmic composition software CsoundAC, the live coding system Strudel, and now Cardinal.