Csound | Hacker News Reader

Csound

csound.com

121 pointslachlan_gray62 comments

Csound has a Web IDE: https://ide.csound.com/

If you are interested in music programming languages, have a look on the languages that Bela platform supports: Pure Data, SuperCollider, Csound, Faust,

and of course, Glicol (https://glicol.org) that I am developing :)

The electronic musician BT released a track written entirely in Csound: https://www.youtube.com/watch?v=ve8WaGmyhfI

I actually met BT and asked him about this track.

While it's mostly written in Csound, he "cheated" with the guitar track, which was a recorded sample brought into Csound.

I can't think of another Csound user that would call that cheating. Function tables and audio file loaders are in there for a reason. Sample away!

I made an album using Csound only. No cheating, no samples, no editing or daw. All you can hear is produced by generative codes (one for each track): https://herva.bandcamp.com/album/seez

Csound is extremely powerful, but my favorite thing in this vein these days is Faust:

https://faust.grame.fr/

It's a functional language with a nice way of generating diagrams of DSP algorithms, but its big killer feature for me is its language bindings, which include C, C++, Cmajor, Codebox, CSharp, DLang, Java, JAX, Julia, JSFX, "old" C++, Rust, VHDL, and WebAssembly (wast/wasm) out of the box.

Csound: A sound and music computing system - https://news.ycombinator.com/item?id=22787566 - April 2020 (90 comments)

CSound for Android - https://news.ycombinator.com/item?id=10794944 - Dec 2015 (12 comments)

I was reminded that there was a guy who wrote a Python wrapper for Csound a long time ago. Apparently it's been superseded by this project, pyo: http://ajaxsoundstudio.com/software/pyo/

Fiddling around at low level can be quite fun indeed.

> Chorth enables Sporth to be run inside of ChucK as a Chugin.

oh yeah, I made that.

Sporth is a stack-based language I wrote a few years ago. Stack-based languages are a great way to build up sound structures. I highly recommend trying it.

Chorth may need some fixes before it can run again. I haven't looked at it in a while, but I had a lot of fun using when I was in SLOrk.

If you are interested in domain specific languages for audio, definitely check out cmajor (https://github.com/SoundStacks/cmajor) It is still in development but already very capable and the devs are working hard to make this the industry standard for audio plugin development.

For low-level sound generation, I'd also recommend checking out my experimental project https://github.com/ClickHouse/NoiSQL

It's unusual because it uses only SQL.

If you want to explore a more functional approach to sound generation, there is always Faust:

https://faust.grame.fr

Visited the grame three decades ago, the guys were forgetting they had an audience because they made an interesting sound during the showcase and started to polish it… passionate people. They were developing in Java if I remember correctly, the software name is escaping me though. Was it Elisa?

Csound can make some incredible timbres, and do amazing things with them. The learning curve isn't easy, and it can be too fiddly for some, but the results can be entirely yours.

It was these two comment threads previously on Hacker News that turned me on to Csound:

https://news.ycombinator.com/item?id=22789920

https://news.ycombinator.com/item?id=22788893

The fact that it is effectively a modular, dataflow system is what intrigues me most about it.

I love csound. I used the eMacs mode and had a lot of fun with it.

How does the Emacs mode work? I'm not interested in going back to Emacs, but I am curious about how the mode works in terms of the newer "real-time" or "live-coding" features of Csound. Do you do something like what's done in this video: https://www.youtube.com/watch?v=eacyGKRBpwA?

I used Csound for a mit reality hack project. What an interesting system!

Csound is... "interesting" and not necessarily in the good way. If you want to play with something similar, but more modern, have a look at https://supercollider.github.io/ instead.

Supercollider! Haven't heard that in a long time. This 2009 article on recreating the THX sound with Supercollider sticks with me:

https://earslap.com/article/recreating-the-thx-deep-note.htm...

How would you say Supercollider is more modern?

To my knowledge, the fidelity of the sounds you can get with Csound far exceed Supercollider. Also, Supercollider has a very restrictive license, preventing its use in basically anything besides small side and school projects, whereas Csound has a very permissive license. I have been doing a fair amount of research along these lines, and although Csound is definitely interesting in the sense of its syntax, it is, as far as I can tell, the most powerful programmatic sound system.

Csound has introduced more real-time features, and you no longer have to rely on a score to make sound. For example: https://www.youtube.com/watch?v=eacyGKRBpwA

> Also, Supercollider has a very restrictive license,

What? SuperCollider is GPL, so it's 100% Free Software.

> preventing its use in basically anything besides small side and school projects

Typically, people use it to create music, so the restrictions of the GPL are no concern.

> > Also, Supercollider has a very restrictive license,

> What? SuperCollider is GPL.

Exactly. That is a restrictive license, and no one is going to use it (it being Supercollider) in anything resembling a commercial product. A lot of these programmatic audio systems make their way into things like installations and video games. Supercollider can't be used in commercial instances except when you're just releasing music.

> Exactly. That is a restrictive license, and no one is going to use it in anything resembling a commercial product.

GPL software is used commercially. Have you heard of Linux?

If you can convince Sony, Nintendo, Microsoft, or any of the game studios to release the code for their games or systems, just so that they can use Supercollider for an audio subsystem, go for it.

If you could convince Sony and Nintendo to upstream everything they customised from FreeBSD (Sony), and clang/LLVM (both), the upstream projects would appreciate, given how they lag behind in GNU/Linux adoption, and GCC in standards compliance and architectures.

Why would they have to release everything else if the Supercollider server is running as a separate process? Just fork it on Github.

If it's packaged with a game, even though it's running separately (is that even possible in a game console?), you would still have to distribute the binaries, would you not? And doesn't that break GPL?

SuperCollider is targeted at composers/musicians/artists, not video game developers, so I don't see how that is relevant.

I shouldn't have even mentioned licensing in my original comment, which was more of an aside that mattered to me in my selection of which system to use, but of course, it's been hyper and myopically focused on here with GPL proponents coming out of the woodwork to argue about it.

However, it is relevant because, as I said, a nice benefit of these sound engines is that they can be embedded in other languages and applications. Thus, when choosing such a sound engine, the licensing is an input to the decision, and other systems, such as Pure Data and Csound, have more permissive licenses. For example, the absolutely excellent iVCS3 app on iOS is built on Csound: https://apps.apple.com/us/app/ivcs3/id665703927.

In your original post you wrote

> preventing its use in basically anything besides small side and school project

That is what I (and others) took issue with. SuperCollider is used by professional artists (including myself). Just because you cannot use it in a proprietary app does not mean it is only for hobbyists!

I did say "in" and not "for", and in the context of discussing a non-permissive license, I think it should be relatively clear about my statement being about incorporating the engine into other software and applications that you may not want to open source. This is why I said side or school projects, because you usually don't care about having to open source those. I did not mean to imply that no professionals use Supercollider to make music and sounds. And really, I was just wanting to point out that Csound can be embedded in several different ways, with a license that is permissive for such uses in proprietary systems.

It's great people are using Supercollider in other ways to make money! But it's obvious that the license doesn't extend to music recordings and performance.

All that being said, do you have any links or descriptions on how you use Supercollider (or any other system)? I'm curious to hear about anything you're able to share.

> I did not mean to imply that no professionals use Supercollider to make music and sounds.

Thanks for clarifying! That was really a misunderstanding then.

> All that being said, do you have any links or descriptions on how you use Supercollider (or any other system)?

Sure! I'm currently AFK, but I'll try to post some links in the evening.

If you want to use SuperCollider as the audio engine of your video game, you would indeed need to comply with the GPL. At least if you want to use the C library (libscsynth). Alternatively, you could run scsynth as a separate process and communicate over OSC; this is a bit of a grey area.

However, most people use SuperCollider as a tool to create music; in this case the GPL does not apply.

> and no one is going to use it (it being Supercollider) in anything resembling a commercial product.

This is patently false.

> > GPL.

> […] and no one is going to use it […] in anything resembling a commercial product.

Ignoring the fact that this is demonstrably false, why would it be a problem if it was actually true?

There is nothing to stop a commercial interest writing their own, or licensing something from elsewhere. Depending on the contribution structure for this project (caveat: I've not looked into this at all) it may even be possible to license this project for non-GPL-compliant use. Or, you know, release the resulting project under the GPL.

The GPL is less restrictive than most commercial licensing, so judging it as restrictive because it can be difficult to justify in some (many?) commercial contexts is somewhat hypercritical IMO. Commercial licences can be just as "viral" and depending on the owner inadvertent infection (by using some code without properly verifying is origin & license first) can be more fatal to a project.

What commercial products are using Supercollider, since you mention this is demonstrably wrong? I'm honestly curious to know about them to read and learn about them.

Many artworks and installations, which I would count as "commercial instances".

You suggest that this is because of the GPL. That GPL covered code is used in many commercial products demonstrates that to be false.

You refrained from answering the question: if it was true, why would it matter?

Supplementary questions: If I release some software covered by, for instance, AGPLv3, why would it be a problem for me that commercial projects wouldn't use it? Why would it necessarily be a problem for my code's users?

We are talking about Csound and Supercollider here. I didn't make any general statement about GPL or licensing, nor would I like to. The entire point is if one wants to do something else with these programmatic audio systems besides just use them as they are to make music, which would almost surely include bundling the software into or distributing with an application, the projects that have more permissive licensing are more attractive for that purpose. And this particularly affects systems like game consoles or other such hardware like synthesizers.

Please just read my other comments and quit arguing about licensing to me. I am much more interested in just hearing about the features and applications of Csound and others.

Csound and Pure Data are more attractive, to me but likely others, because I can freely bundle them and apply them as I please without tiptoeing around a license, not to mention they have their own pros as far as sound generation goes. Supercollider was presented as an alternative to Csound, but I simply pointed out that if you care about embedding the system into something else, Csound is more friendly to that, as is Pure Data.

> quit arguing about licensing to me

If you don't want to discuss something, may refrain from bringing it up?

If it isn't a relevant point when discussion these specific products then your mentioning of it in criticism of one of them seems [short pause to think of a more generous word than the first one that sprang to mind…] odd.

It's been discussed, people are bringing up irrelevant examples and generalizing what I said out of context, including you who quoted my comment by removing the context, and it's a fact that Csound has a more permissive license.

You have somehow acquired a misunderstanding of the GPL. It does not forbid commercial use.

Did you read my original comment to understand the specific context and many followups? Because I was talking about embedding programmtic sound engines like Csound and Supercollider into other software and applications and distributing them, which the GPL license of Supercollider does indeed prevent unless you want to open source those applications.

> How would you say Supercollider is more modern?

Reasonable syntax, naming, errors, etc. Csound feels like programming assembler. Yeah, you can macro and it's powerful, but... it was far from fun for me.

Yea, the Csound syntax does take some getting used to. But I just haven't found a demo of Supercollider that I feel sounds good. It all sounds pretty glitchy and digitally, for lack of a better word. But the interaction of Supercollider does seem nice.

They're certainly both very cool, as well as their other brethren like Pure Data, Max, Audiomulch, Faust, ChucK, etc.

I'm not sure I understand. An oscillator in csound should sound the same as one in supercollider. The rest (what you build) is up to you. What do you mean by glitchy in this case?

I've never used either Csound or Supercollider extensively (more of a PD guy), but having tried to write a simple oscillator in pure C, even that turns out to be non-trivial. The naive approach of sin(t * pi2 * freq) produces pops when varying the frequency - you need to keep track of current phase. And from there it begins, the further you dig the more things you find you thought were trivial. I wouldn't be surprised if this or that synthesizer got something wrong.

Did you continue on your own writing synthesis in C? Any resources you found helpful?

Back when I was writing a software synth for fun (and also for getting hired in the audio industry), I found the book DAFX to be very helpful. It describes basic algorithms for doing digital audio, though not the state of the art.

There's a ton of information on DIY VST sites like KVR. https://www.kvraudio.com/forum/viewforum.php?f=33

Most VSTs are written in C++ rather than pure C to be compatible with VST wrappers, and also because a bit of class management simplifies some parts of the coding.

There's no particular advantage to using pure C.

The basics - oscillators, filters, envelopes, and such - are all solved problems, although you'll need to get up to speed on basic DSP concepts like aliasing, IIR vs FIR filter designs, and such.

More sophisticated filter types use numerical approximation to solve the filter equations. That gets a little more complicated.

And of course you can look at the source code of Csound and Supercollider.

Thanks!

> The basics - oscillators, filters, envelopes, and such - are all solved problems,

When you say this, are there any good reference materials (i.e., books or papers) of the algorithms?

Reading other people's code helps a lot! Browse Github topics like "synth", "synthesizer", you can also narrow it down by language (C, C++, D, Rust, and Go are all fairly easy to translate between one another). I haven't looked at any of the theory stuff, which would've probably helped too.

I kind-of abandoned the project before I could figure out what went wrong when rewriting it to keep track of the phase. I understand what needs to be done, I just have a stupid bug somewhere down there and it kinda demotivated me.

Thanks! Part of my issue is that I cut my teeth on functional languages, so I am quite wary of C++, which makes this hard. I'm indeed looking to pick up Rust or get more practice with C, as there isn't that much choice beyond those.

The hardest part is probably manual memory management, and getting used to expressing solutions using iteration rather than recursion?

I don't like C++ (and have mixed feelings about Rust) because of how large and complex the entire language is. If you'd like a stopgap where you can still enjoy the functional style, and don't mind compromising on raw performance, Python is great. The operator syntax is also quite close to C, and you do get bindings to GStreamer in case you decide to take your audio project in new directions.

I roll with F# these days, which does imperative programming nicely and can reach out to unmanaged DLLs. I agree with not liking C++ and being hesitant about Rust, as it brings its own complexity. At least C is simple, but often too simple.

You might enjoy my project called sndkit [0]. It's a collection of DSP algorithms implemented in C, written in a literate programming style, and presented inside of a static wiki. There's also a tiny TCL-like scripting language included that allows one to build up patches. This track [1] was made entirely using sndkit.

0: https://pbat.ch/sndkit/

1: https://soundcloud.com/patchlore/synthwave

Sounds interesting. I'll have a look.

I don't have a technical argument offhand, as my understanding has built up over reading and some use of Csound. My main source has simply been my ears in listening to demos of both Csound and Supercollider and me finding that most of the Supercollider stuff all sounded the same and quite digital. Although I like it, I think Pure Data actually has the same problem. I would wager it simply boils down to the synthesis algorithms used, and Csound definitely also has a huge library of those. I have also seen some examples of Csound being used to synthesize via physical modeling. But I am still getting into all of it.

If you compare codebases, SuperCollider is definitely the more "modern" of the 2. SC is written in a reasonably modern version of C++, and over the years has gone through significant refactoring. Csound is mostly implemented in C, with some of the newer bits written in C++. Many parts of Csound have been virtually untouched since the 90s.

Syntax-wise, Csound very closely resembles the MUSIC-N language used by early computer musicians in the 60s. "Trapped in Convert" by Richard Boulanger was written in Csound in 1979, and to this day is able to run on the latest version of Csound.

Both Csound and SC are both very capable DSP engines, with a good core set of DSP algorithms. You can get a "good" sound out of both if you know what you are doing.

I find people who are more CS-inclined tend to prefer SuperCollider over Csound because it's actually a programming language you can be expressive in. While there have been significant syntax improvements in Csound 6, I'd still call Csound a "text-based synthesizer" rather than a "programming language".

That being said, I also think Csound lends itself to those who have more of a formal background in music. Making an instrument in an Orchestra is just like making a synthesizer patch, and creating events in a Csound score is just like composing notes for an instrument to play.

FWIW, I've never managed to get SuperCollider to stick for me. The orchestra/score paradigm of Csound just seems to fit better with how I think about music. It's also easier to offline render WAV files in Csound, which was quite helpful for me.

I have programming experience, but that's actually why I prefer Csound. Since Csound's engine is effectively oriented around building up instruments in a modular way, I feel it can simply be wrapped up into more general purpose programming languages to get a language with the power of the more modular synth engine.

None of these languages have ever been on the level of Reaktor IMO and I started in csound quite awhile before Reaktor.

You don't gain almost anything with these languages in their current forms because they end up not being much different than modular patch cord synthesis with a less intuitive interface.

The amount and variety of interesting sounds I have heard from Reaktor is several orders of magnitude beyond csound to a degree it isn't even comparable.

I might even rate these early versions of AudioLM as already more interesting than csound.

The whole idea of music programming languages is a dead end IMO.

Reply on news.ycombinator.com