Patterns and Ndef are optional

I haven’t used Patterns in years. If they don’t appeal to you for whatever reason then you can always use Routine and Synth. Watch out for OSC pre-emption, which is done automatically in Patterns but not in Synths. You must wrap certain Synth-related calls in Server.default.bind { ... } to ensure accurate timing in a sequenced piece. I wrote a mini-article about this.

I’m often asked why I don’t use Patterns. I expect to eventually write a blog post that answers that at length, although I have to figure out how not to go into a rage-filled diatribe about the default Event type.

Ndef, ProxySpace, etc. are collectively known as JITLib. As they are primarily built as a live coding environment, for non-live coders their advantages are not particularly strong over just using Synth.

Don’t install tons of quarks or third-party plugins

I wrote a post about this called “Uninstall your quarks.” I don’t even have sc3-plugins installed anymore these days. The constraint of doing everything in vanilla SC is weirdly liberating. Your mileage may vary.

Find non-SC production tutorials and translate them to SC

This is the single biggest thing that helped me reach a point where I was actually happy with my own SC music. The dance and hip hop production communities on YouTube have a wonderful collection of free learning resources. Even if you’re more interested in more experimental genres, the fundamentals of making drums, pads, keys, bells, etc. are critical to build up to more left-field sound design. Channels I recommend are: SeamlessR, Au5, Bunting, Mr. Bill, Ned Rush.

Gordon Reid’s “Synth Secrets” articles are often recommended. There’s useful stuff in there, but being magazine articles they aren’t accompanied by sound examples, which is problematic for learning sound design. I highly recommend sticking to learning resources where you can actually hear the instructor’s results.

Look up commercial audio products and try to clone them in SC

I keep up with cdm.link and a few “synthfluencer” YouTube channels (Sarah Belle Reid, Benn Jordan, Richard Devine, the VAPE) to learn about the latest hardware synths, Eurorack modules, VST plugins, etc. Cynically speaking, a lot of them are about showing off overpriced toys, but as a converted disciple of the ‘Collider, you are permanently cured of Gear Acquisition Syndrome! If a particular piece of gear sounds interesting, then download the manual, watch a demo video, and see if you can remake parts of it in SC code. Don’t make a GUI, just replicate the sound. Even if you can’t get a perfect clone, it will certainly give you ideas for patches.

Practice coding from scratch

Because it’s so easy to copy-paste text, beginners often treasure and recycle snippets of SC code, written by themselves or others. In the particular case of sound design, I recommend against this because the physical process of writing and tuning patches is incredibly important for building fluency in SC. Become a SynthDef-making machine. Write so many SynthDefs that they become ephemeral and disposable, like patches on a hardware modular synth. If you constantly hold on to SynthDefs rather than writing new ones, you’re discouraging yourself from exploring, which I’d argue ultimately leads to stagnation as a sound designer.

If you are an experienced programmer, this may require a change in thinking. SC is not like a standard software engineering environment where code is written once to fulfill a utilitarian purpose (modulo maintenance and refactoring). Instead, SC is an instrument that has to be practiced, and the process is as important as the result.

“Practice” is the key word in this. Every few days since 2016, I do an SC practice session saved to a directory in Dropbox, named like 2023-03-16-electro-swing.scd. I don’t habitually revisit old patches unless I’m bored and want to wince a bit at how my sound design was five years ago.

If you’re new to programming, get honest feedback on your code from SC users

In the software industry, an ideal code review not only catches problems before production but also helps educate everyone involved. Self-taught programmers in particular can get into weird habits. Having an experienced programmer look over your code can permanently improve your abilities.

If you’re new to music production, get honest feedback from producers

The biggest reason I recomend this is mixing. The best way to learn to mix is to get personalized feedback from a professional audio engineer who appreciates the genre you’re working in. I’m not an accomplished mixing engineer myself, but I am blessed to have friends who will tell me that I need to cut 12 kHz and above by exactly 4.5 dB, and also that hi hat is garbage.

Also, if you intend to use conventional Western harmony and melody and you’re self-taught in that domain, I do recommend lessons with a composition or jazz piano teacher if you can afford them. Once I attended a concert by someone who played a Bach prelude on the piano with all the accidentals confidently wrong. Self-learning is great, but there are dangers too.

Don’t build ambitious software projects in SC

sclang and its class library are pretty janky, and my experiences building and maintaining larger projects in them have been less than ideal. For those reasons I have mostly stopped building major sclang projects for my own practice. I don’t always mind working on software engineering in place of music, but sclang as an ecosystem has major issues with error handling, error message readability, and debugging tools, and it can result in a lot of frustration.

Programmers coming to SC often get stuck in this mindset that they can only employ SC in a musical context if they start building a wrapper around SC so they can “properly” use it. This is like building a pianola so you can play the piano – it’s fine to do that, but it’s not actually making music. With some creativity, the raw SC interface is already perfectly ripe for artistic works, if you think of it as an instrument rather than an API. If you need examples of what such a process looks like, I use SC in exactly this way in my YouTube channel.

If you decide to break this guideline, proceed with caution. Keep your software rudimentary and only architect complex features if you’re 100% sure that they will pay off as better art. Your audience hears cool music, not cool software, so be conscious of diminishing returns. It’s also critical to psychologically separate your music from your software: maybe spend a week on maintenance, then freeze the code for a week just to make music, and repeat. You could also hire someone else to build or maintain the system for you – I’ve freelanced for artists who have done exactly that.

Also, don’t make the one big patch that does everything. That’s setting yourself up for failure. SuperCollider is the one big patch that does everything.

Conclusion

Good luck on your SC journey! The people at scsynth.org are always around to answer questions, but if you specifically want my thoughts or feedback on something, I’m always free to chat about SC, signal processing, and music tech in general by email. (If your questions are numerous or complex, feel free to get in touch about private lessons.)