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.
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.
> > 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.
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.
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 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?
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.
> 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.
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.
> […] 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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