#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!

One obvious advantage for WASM is that it will run just fine in every common browser on every operating system.

But there is a potentially equally important advantange in that WASM modules should soon be able to call into the browser, into the browser’s document object module, and into other WASM modules. It is this last clause that should arrest your attention. It means that WASM could soon support an immense ecosystem of proven, debugged, high-performance, reusable libraries, even more so than Java, JavaScript, Python, or .NET. Csound itself is of course an example of such a WASM library.

This has all almost happened before. It used to be the case that Web browsers would run Java applets, and there was an easy interface between JavaScript and Java classes in the browser’s JavaScript context. This cool possibility was killed because corporations did not like (indeed, nobody liked) the security loopholes it brought.

The WASM ecosystem is more likely to take hold because (a) all the major browser and Internet corporations currently support it, and (b) the WASM runtimes in browsers rigorously enforce the same security sandbox that contains JavaScript code. This sandbox is what prevents code from one Web site being tricked into running malicious code from another Web site.

One may wonder: Why not get rid of the operating system altogether, or rather, replace it with a thin layer that runs applications as WASM modules? I see absolutely no reason not to do this.

Operating systems, of course, could be modified to bring the same advantages to regular “desktop” applications and libraries. That would mean installing a WASM runtime as a standard component of the operating system, like bash on Linux, and having the OS automatically run WASM applications. It would also most likely mean adding to standard compilers such as gcc a built-in option for compiling to WASM. If operating system designers and maintaners are not, indeed, asleep at the wheel, then that will happen (this option has clearly been foreseen and provided for by the WASM designers).

Again, this has almost all happened before. Microsoft’s .NET virtual machine promised this kind of inter-operability, and it was extended to Linux and the open source world with the Mono project, which is still alive. But .NET did not take over the world. Possible reasons include lack of native speed, and bias against MIcrosoft, 

But it doesn’t matter. Mono has been ported to WASM.

Indeed many languages now compile to WASM, see this list.

Okay, now for the concluding punch line. 

If, in addition to Csound, other computer music systems, applications, and libraries were compiled to WASM, then they could all talk to each other. JavaScript would serve as the universal scripting language/glue code. This would at least make it possible to break through the silo walls that have tended to technically isolate different communities of computer musicians. Note that JavaScript itself is now a fairly high performance language.

Systems that I would particularly like to see ported to WASM include OpenMusic, Common Music, Grace, Pure Data, SuperCollider, Max, LilyPond, and MuseScore. Some of these would require first porting Scheme or Common Lisp to WASM. That in turn will require adding to WASM a garbage-collected memory manager.

In his keynote, Steven Yi mentioned some things other musicians say when they learn he uses Csound:

You use Csound?

People still use that?

It’s so old...

Is that the sound of Csound?

I’m a musician, not a programmer.

I will offer my thoughts about these things, which I also have heard, but first I think there needs to be some context regarding electroacoustic music in particular, and art music in general, in our world. 

Art music is music that either is designed just for listening, or that is meaningful when used for just listening. My impression is that our civilization continues to educate people pretty well for the purpose of producing art music (and indeed electroacoustic music). But our civilization does not use this music in the same ways that it used to. The most obvious sign is that, on the one hand, the concert halls are full of grey heads while, on the other hand, the streets and offices are full of people wearing earbuds that place them into their own private bubble of music. It is not even easy to find out, without disturbing the listener by pulling him or her out of that bubble, what they are listening to.

Regarding electroacoustic music, its audience is, as with poetry, mostly the artists themselves. This is a larger and often vibrant bubble, but it is still a bubble. In other words, the world of high art is fragmented and esoteric, and there is no canon that society as a whole pays any real attention to.

I am by no means rendering a purely negative judgment here. There is actually tremendous freedom in this situation. It is easy to get an education, or to teach oneself as I have done, to find a way into one of these bubbles, and lead a productive and rewarding life in it. Above all, what used to be very expensive tools reserved for an elite are now widely available and often even free. This is a great freedom. But it is isolated. And this isolation is undoubtedly a factor in the alienation that passivates us and that will, if unchecked, lead to tyranny.

Now perhaps my responses to Steven’s observations may make more sense. The people asking these questions live in a different bubble than we do, both artistically, and technologically. Their remarks are naive and reflect presuppositions.

You use Csound? This identifies the questioner as being from a different bubble. Nobody they know uses Csound, but other tools with their own mystique, perhaps one formed by advertising.

People still use that? Ditto. The questioner knows what Csound was, but not what it is. There is an awareness that Csound was invented in the age when expensive computers were reserved for an elite, which generates an implicit assumption that this is now overcome by tools that are easier to use and more fun.

It’s so old... Ditto ditto. Again, this reflects the culture of the moment, where only the new is the good, and it implies an eagerness for tools that confer an instant gratification (nothing wrong with that, by the way, as long as it doesn’t preclude other approaches). There is no awareness that if Csound is 30 years old, that means scientists, programmers, and musicians have been adding onto and refining Csound for two or even three generations of artistic and scientific work. Somehow old is good for a city, but not for a software system. The reality is that the basic Music N design by Max Mathews and the translation to elegant C code by Barry Vercoe require, in the fundamentals, no revision, and they provide solid support for extension. The situation is similar with respect to some other software systems such as database servers and languages, symbolic algebra programs such as Mathematica, or the LaTeX computer typesetting system, all born in the same era as Csound and also still going strong. In short, other things being equal, older is actually better; well-designed software systems just keep getting more and more powerful, and Csound has a head start.

Is that the sound of Csound? The questioner assumes that older software will sound inferior to newer software. This of course is simply not (usually) true. A digital oscillator is a digital oscillator; a digital filter is a digital filter. Furthermore the continuous refinement and extension of Csound have brought into it many techniques from research and from other computer music systems. Studio software is made from the same parts, so of course Csound will normally sound as good as the best studio software. But there is more to this. There is another assumption, namely that the user is passive and not able to improve the sounds that come out of the box. The fact is, that with experience, the user is significantly able to improve the sounds that come out of the box, and to invent completely new sounds. But this takes work and thought... more on work and thought below. At any rate, given a little work and thought, Csound will sound better than the best studio software (with some notable exceptions that I will not go into here and that we should address in another place). Some of the pieces in the conference were proof enough of that!

I’m a musician, not a programmer. Actually, I believe this question can be better understood by rewording it. I’m a musician, not a researcher or an inventor. I’m a musician, not a thinker.

To go back to the question of art music, you can’t make art music without thinking. But thinking is painful. So why make art music? This is the real question, the final question. Because I like it. Why make computer music? Because I like it.

Helping more people like art music is a question for another forum. But I do think we can help people who already like art music, or who already like computer music, find out if they like the kind of music that can be made with Csound, and that is what this about.

So, in my view, one productive response to the questions asked of Steven Yi is to make music made with Csound more impressive, more available to musicians, to make it easier for them to see if they like it. The music needs to come out of our bubble and perhaps find a way into other bubbles. How to do this may have many answers, but I propose that part of the answer can be an online system similar to SoundCloud or ShaderToy where Csound users can easily post complete works that will end up being sorted by popularity and other criteria so that the best, or at least the most popular, works will be easily accessible to non-Csound musicians. or even, mirabile dictu, regular people. This can be done using the WebAssembly build of Csound so that what one hears can be rendered live by Csound running in the listener’s browser.

For the sake of those who, like myself, actually wish to make money from music created with Csound, this portal could also perhaps be designed to post soundfiles and/or videos to YouTube, if the musician posting the piece has the required registrations with Google, AdSense, and so on. (I know that CDBaby automatically posts videos of pieces from CDBaby CDs to YouTube; when I went to post some of my pieces to YouTube, I found that CDBaby had already put them there.)

I have made this change after carefully reviewing our agreements such as the Csound LGPL v2.1 license, the GPL FAQ, the Steinberg VST SDK licenses, and the terms of use of GitHub and AppVeyor, and the code bases and licenses used by a number of open source projects that use the VST SDK. A summary of my research can be found in the Csound GitHub repository at https://github.com/csound/csound/blob/develop/Opcodes/vst4cs/licensing_considerations_for_csoundvst_and_vst4cs.md

In addition the AppVeyor build, which happens automatically for every commit to the Csound Git repository, documentation at https://github.com/csound/csound/blob/develop/msvc/README.md shows how to perform the AppVeyor build locally to produce the same Visual Studio build of Csound with all the same features. The only requirement is that you build on Windows 8 or later with Visual Studio 2015 or later.

Such a local build is advised for Csound developers working on Windows, for it produces a Csound.sln solution that can be loaded into Visual Studio for fast incremental builds and excellent debugging facilities.

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.