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.

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

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.

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?

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.