💾 Archived View for oberdada.pollux.casa › gemlog › 2023-10-28_csound.gmi captured on 2023-11-04 at 11:10:23. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Someone on gemini recently mentioned a programming language with the stated goal that it would not expand or change much in the future. I think it might have been the Hare language, which will develop towards a version 1.0 and then it will be done. A bold vision, indeed.
Csound, a domain specific language for audio work, is at the other end of the spectrum. Constantly evolving it has incorporated numerous additions, a few helpful ones and a lot of redundant replications of slightly different ways to solve the same problem. The language has become some sort of assemblage where any programmer can come and glue their little piece of software band-aid on the edifice with little regard for the structure of the whole thing. The user has to cope with an ever expanding set of syntactical constructions, some of which make life easier, but not always, and an even more rapidly expanding set of opcodes, the rough equivalent of keywords in other languages.
I was first exposed to Csound in the mid 1990's when it was at version 3 something. There were already several alternative ways to make it turn out a sine, but the list of opcodes was still manageable, you could learn most of it in a few weeks. Today, I don't envy the novice considering to learn Csound. The reference, where you have to go to look up the syntax and the expected parameters and return values of each opcode, has grown so enormous that it tests you patience to search through it. It's not that it is badly written or poorly structured; there are lots of useful cross-references and examples, but there is simply too much of everything. I suspect this partly explains why Csound doesn't seem to enjoy as much popularity today as it might. It could also have to do with the reluctance among musicians and composers about having to engage with text interfaces when they are accustomed to convenient GUIs. MAX/MSP and Pd appear to be much more popular, after all. I haven't seen any statistics though, this is only my impression from how often these languages are mentioned in various projects.
Just in case someone actually is trying to learn Csound today, I have written a short manual, an incomplete guide to Csound. It is incomplete only in the sense that it does not cover everything you can do with Csound, in fact I have no idea of most things that can be done and which have been added in recent years. My idea is that efficient usage of a tool like Csound is possible only when you have internalised the part of its syntax and keywords or opcodes that you really need to use. Taking stock, I have found about twenty vitally important opcodes, a number small enough to commit to memory.
I have no idea what it is like to develop code for a giant project like this one. My suspicion is that after a while, as currently active developers leave the project, new ones will find it exceedingly difficult to enter and grasp the structure of it. The language is full of ill conceived design decisions. In C, we are familiar with the switch structure's redundant break at the end of each case; equally stupid remains of bad initial decisions litter the Csound language. There are also some smart design decisions, such as a naming convention that defines the type of a variable by its initial letter, and a simple syntax where each statement consists of three columns: a variable, an opcode, and its parameters.
I don't know much about SuperCollider or ChucK, or any other comparable sound synthesis language. Maybe they have solved some of Csound's weaknesses. Otherwise, I think there is a case to be made for a Csound fork which keeps the essentials, some 20-30 opcodes and simple syntactical constructs, does away with redundant constructions such as three different versions of an oscillator, and tidies up some of the failures such as the overly complicated control structures. Some of the complexity derives from concerns with computational efficiency, at the detriment of audio quality, including the separation into audio and control rates. It might be worthwhile to make a minimalist fork of Csound where the software is as small as possible. Another fork might cater to small and slow computers.
For my part, I'm not a programmer, so I use forks and knives only at the kitchen table.