The SuperCollider sound server scsynth is one of the most finely tuned and efficient synthesis engines out there. For most people on most modern computers, they will rarely meet limitations in terms of effeciency. That said, scsynth does have one potential for optimization: Parallelization. And this is where supernova comes into the picture. The original scsynth sound server in SuperCollider, like lots of other audio software, runs on one core and so your computer’s single core performance is a big limitation for the possibilities of scsynth.

SuperCollider is my favourite programming language for music and sound and I use it all the time. The programming language comes with an IDE that is quite capable, but I for one prefer doing all of my coding in one editor (sometimes I write C++, lua and SuperCollider in one and the same project and this allows me to do it in just one editor instance) and that editor for me is NeoVim.

These notes are for setting up a new audio system on Arch Linux. It is assumed that you have an AUR helper like yay or paru installed (I use the latter here but exchange with yay if you use that). This isn’t a tutorial but just a collection of notes to help myself and perhaps others setup a high performance audio system in Arch Linux. The Arch Linux maintainers have done an amazing job in making it a good operating system for this kind of work by allowing users to easily setup the system with the right privileges and install the needed software.

These are notes that I gathered for myself while setting up and installing a dual boot system on an old laptop that I repaired and resurrected. The laptop has a 1TB hard drive so it’s got plenty of space for fun stuff like this. The first step is to install Windows. I won’t cover that here. I installed it on the first 100GB of the 1TB hard drive and then rebooted from the Arch Live Iso to start the arch installation to take up the rest of the drive.

I do all of my production work on Arch-based Linux systems these days. This is generally a pleasent experience since Reaper started supporting native Linux builds and yabridgectl made bridging Windows VST Plugins quite breezy and effective. Once setup correctly, this offers a performance experience and workflow that I think is quite close to native. One advice that I kept hearing again and again though was to install wine (the Wine program that lets you use Windows software on Linux) using wine-tkg, a customized build system for installing.

I recently bought one of Bela’s Trill sensors - a really nice multitouch capacitive sensor that comes in various shapes and sizes (and open source hardware !). Capacitive touch sensing is something that has been used in analog modular synthesizers for half a century. The main attraction for me as an artist is that it is incredibly response as opposed to the bulky rubber buttons you get on terrible commercial midi controllers or even high quality switches: As soon as you touch it, it sends off a signal (as opposed to a hardware button where the button has to be pressed to the point where it triggers - it sounds like nothing when put in to writing but the difference in responsiveness is incredible).

Update February 2022: faust now comes with the faust2sc.py tool to make this all a lot easier. The instructions below have been updated to reflect that. I recently started toying around with Faust. Faust is a functional programming language specifically designed for audio manipulation. One of the many strengths of Faust is it’s compiler backends that allows the user to compile Faust code to almost any end target - including microcontrollers, JUCE/VST plugin projects, Pure Data, Max and SuperCollider - with the same Faust code.

My amazing workplace allowed me time during the Covid-19 lockdowns in Oslo to spend time improving my C++ and DSP skills. The result of this is a bunch of plugins for SuperCollider, some of which are already released as well as a trunk of Notam plugins that are to be announced. The process of creating server plugins (aka UGens) for SuperCollider is one of the most fun and gratifying ways one can experiment with DSP and C++ in my opinion.

I recently got hold of Electro-Smith’s powerful Daisy Seed microcontroller board for developing embedded DSP projects. Unfortunately, at the time of writing the libraries for it do not support Platformio fully which is normally my preferred way of working with microcontrollers but fortunately it’s pretty easy to setup and use using make. Here are my notes for doing that. Install prerequisites (on Arch) # yay -S dfu-util gcc-arm-none-eabi-bin Setup and build libraries # From the root of your project:

Since the main SuperCollider github repository moved to using Github Actions to automatically build, compile and release cross platform, I felt intrigued to use the same technology to do the same for SuperCollider plugins. There is a number of amazing SuperCollider plugin repositories on Github - a lot will demand that the user compiles the sourcecode themselves to use the plugins. For people used to CMake and/or a Linux-ey workflow of compiling, this is not a big problem but for a lot of others (most people perhaps), it really is a doorstopper.

I recently built version 2 of a “master volume control” midi controller that I had made before. This version is slightly improved on the former, the main improvement being that if you press the button while booting the device it goes into 14 bit midi mode (leveraging 13 of the Teensy’s bits for this) to allow high resolution on the potentiometer’s input. The controller is very cheap and simple to make.

Mutable Instruments is an absolutely amazing synthesizer company that produces open source hardware with open source firmware on it. I have several of these and I love poking around in the firmware (check out this brilliant tutorial om how to do the same). The company has even open sourced it’s development environment which on most systems may be setup in a virtual machine. But this is not so easy on Arch Linux, since these virtual machines rely on old(er) kernels, and I am always on bleeding edge kernel versions on my development laptop, so I decided to setup my own little development environment for hacking Mutable Instruments (and similar) firmwares directly in Arch with no virtual machines used and it seems to work quite nicely.

This is a transcription of Dan Stowell’s very helpful table in the SuperCollider Book (MIT), slightly edited and transcribed for the “new” c++ style for writing plugins. It contains some of the macros available when writing UGens/Plugins in c++ in SuperCollider. This repo contains example code for writing plugins in both the “old” and “new” style which I found helpful in understanding this subject. Also check out this cookiecutter template for generating plugins and the Server Plugin API.

This post is a collection of notes on how to write plugins for SuperCollider. This post will be updated as I go along. Useful links # This repo contains example code for writing plugins in both the “old” and “new” style which I found helpful in understanding this subject. Also check out this cookiecutter template for generating plugins and the Server Plugin API. The two different styles # There are two different headers that contain SuperCollider’s plugin boiler plate code.

Lately I have started experimenting with the very cheap and powerful ESP32 microcontrollers. Today I made a simple example of a firmware which receives OSC from a computer and then blinks the on-board LED according to the incoming message and I packaged it all as an easy to clone/copy/use platformio project (mostly for myself). The firmware uses CNMAT’s OSC library: #include "Arduino.h" #include "WiFi.h" #include <OSCMessage.h> WiFiUDP Udp; // A UDP instance to let us send and receive packets over UDP int LED_BUILTIN = 2; // Options int update_rate = 16; // Network settings char ssid[] = "wifiname"; // your network SSID (name) char pass[] = "wifipassword"; // your network password unsigned int localPort = 8888; // local port to listen for OSC packets void setup() { pinMode(LED_BUILTIN, OUTPUT); /* setup wifi */ WiFi.

Lately I have been experimenting with 14bit MIDI and found it to be a huge revelation for my work with SuperCollider. Often, the regular data range of MIDI (0-127) is way too choppy and coarse for nice interactions with your systems and instruments in SuperCollider, but 14 bit MIDI provides a resolution of 16384 steps which is great. This is actually achieved quite cleverly by combining two MIDI CC signals in to one.

Inspired by this blog post, I have been toying with a silly idea lately: A completely portable Arch Linux distribution set up properly for computer music, but flashed onto a USB thumb drive so that I may pop it into any computer, boot from the thumb drive and start creating music on whatever hardware is in front of me. I have achieved this now using the awesome alma project. Alma is a tool for creating persistent USB installations of Arch Linux using a series of configuration files and bash scripts called presets.

One of the big hurdles for me when switching from a Mac based audio setup was the potential loss of access to my expensive collection of VST plugins (because a lot of developers still ignore the Linux platform as if it was 1995 even though it has never been easier to make and release cross platform plugins). Little did I know that almost all of them would run just fine on Linux using the wine Windows compatibility layer and the yabridge or linvst VST plugin bridging software.

These are notes I have been taking while making packages for the Arch User Repository, a community based package repository for users of Arch Linux and it’s derivative operating systems. This isn’t a complete guide and certainly not beginner friendly but should help some people with some linux experience get started. If you have a tolerance for YouTube videos, then maybe this video will be helpful to you. It is also recommend to read the official guide on how to create packages: Creating packages.

These are workshop notes for the online introductory SuperCollider workshop put on by Notam in September 2020. It covers the basics of using the pattern library in SuperCollider You can download the notes here: workshop-notes Design # Short history of SuperCollider # SC was designed by James McCartney as closed source proprietary software Version 1 came out in 1996 based on a Max object called Pyrite. Cost 250$+shipping and could only run on PowerMacs.

A cloud generator is basically a synthesis process that generates a lot of micro sound events (grains) at the same time. This as a whole becomes a bigger textural structure called a “cloud” generally. I have done a lot of experiments lately using SuperCollider’s pattern library to sequence micro compositions on a per-sound-particle basis, but to take a break from that work (which rarely leads to succesful results I have to say), I challenged myself a bit and tried to make an audio rate granular synthesis cloud generator.

Today I did a small experiment with my Raspberry Pi 4: I wanted to poll the GPIO data pins and use data from them in SuperCollider. This is best done by polling the pins in a separate program and then sending that data to SuperCollider via OSC. I have done this in Python before but I much prefer doing this kind of thing in Rust since the latter is fast and safe (and just generally: I love Rust!

These are notes for setting up YouCompleteMe - a program for autocompletion, code linting and debugging in the text editor Vim - for developing Rust programs. I find this program vital to my Rust workflow because it allows me to more easily explore code and correct mistakes before they reach the compiler. YouCompleteMe will tell you if there are syntactic mistakes in your code, it will tell you about unused variables and code and it will often suggest changes to problematic code.

At the beginning of the Covid-19 crisis the Danish artist Claus Haxholm reached out to me to do an interview by email. It turned out to be a lengthy email exchange which resulted in an interview available on the Danish music website Passive/Aggressive. In the interview (which is in Danish unfortunately) I talk about the brain, morphology, Norway, time and different speculative subjects related to computer music, as well as my Vortex system.

My Ornament & Crime build (the Mini OC version). The USB connector on the Teensy on the back of the module has been rewired to a Neutrik USB connector attached to a panel next to it (the grey panel). I have tried quite a few different approaches to integrating my modular synthesizer with my SuperCollider workflow and I have found most them to be disappointing, extremely expensive and or inflexible.

Jack is an incredibly flexible piece of software for making audio connections. It’s mostly used to connect and patch virtually within one computer but it has a range of amazing extra features for connecting things in alternative ways. This is exploited to it’s fullest in the zita-njbridge package. To quote from the manual on zita-njbridge: The zita-j2n (sender) and zita-n2j (receiver) applications allow to exchange up to 64 channels of full-quality uncompressed audio streams between two or more systems running the Jack audio server.

These are notes for setting up a Raspberry Pi 4 single board computer for pro audio work. Specifically for running SuperCollider programs for interactive installations. I used Raspbian Lite for this, since my intention is to run the Raspberry Pi in headless mode, meaning using no display and no desktop environment (to save resources). It is presumed that you have installed Raspbian on an SD card, with ssh enabled (allowing you to log in to the pi over the network and execute commands using a terminal), and that you are logged in.

A while ago I started compiling a list of links to SuperCollider based things that I found interesting and wanted to save for later. The list grew and at one point I organized it all in one public repository where the SuperCollider community could help curate links to awesome SuperCollider things and it has since then become a truly rich resource for things like tutorials, reading material, nice projects and tools.

Nannou is a relatively new framework for creative coding ⨪ kind of like processing, openFrameworks and cinder. A creative coding framework usually consists of a cluster of tools for working creatively with audio, visuals, robotics, lasers and many other things in one coding framework, and nannou is no different. The great thing about nannou is that it is a framework making use of the cool new systems programming language Rust.

In this tutorial, I will cover how to install and setup SoX on android devices using Termux. Termux is a free “Android terminal emulator and Linux environment app that works directly with no rooting or setup required”. Basically it is a command line interface for your Android device and works like a small linux distribution. It even includes a package management system. And if you get something like an OTG-dongle you can even connect a keyboard and/or a class compliant sound interface.

To make full use of SoX’ potential for batch processing we will be using a bit of command line wizardry. The idea is to put our sox command inside of a for-loop which iterates over all audio files in the folder you are currently in. If you are unsure of what folder your terminal is executing from, you can write pwd to see it’s full path and ls to see the folder’s contents.

SoX has a very effective and rather precise way of semi-automatically chopping a sound file into smaller sound files. Let us say you have a sound file containing many different sounds seperated by a bit of silence in between. It could be a series of drum hits that you have recorded off of a drum machine. To make these sounds easy to use, you most probably need them as seperate sound files so you can load them into a sampler or other software as a sample bank of sorts.

SoX is a very powerful command line audio processing tool. You can think of it as a sort of command line equivalent of Audacity but with a text based interface that let’s you perform powerful audio operations by typing just a few words in your computer’s terminal. I came across SoX via the live coding community where it is a popular tool for chopping sound files (by detecting silence) and batch processing large quantities of audio files (eg.

It is possible to get a nice development environment on Linux (and other platforms) using NeoVim and a few plugins and settings. This dev environment includes snippets, autocomplete, debugging and smart code suggestions for methods. I got a lot of pointers for this setup from Chendi Xue’s blogpost about Vim/CPP development. So, without further ado here are my notes for setting up shop using YouCompleteMe, UltiSnips and some formatting plugins.

Here are the slides for the SuperCollider workshop at Notam, january 2020. Download slides Algorithmic composition using patterns # Notam, january 2020 # About me # Name: Mads Kjeldgaard Occupation: Composer and developer Work: The Norwegian Center for Technology and Art (Notam) Notam # Development for art projects (hardware, software, tech and artistic guidance) Communities / meetups (SC meetup among others), see website notam.no Studios / 3D sound / VR / Visuals / Electronics Courses My practice # Computer music / livecoding Concrete music Cybernetic / systemic music Contact info # mail: mail@madskjeldgaard.

Here are the materials for the SuperCollider workshop at Herlev Bibliotek, Denmark, November 2019. The SynthDef used for the workshop [can be downloaded here.][1] Download slides here. SuperCollider workshop # Herlev Bibliotek, Denmark, 2019 # About me # Name: Mads Kjeldgaard Occupation: Composer and developer Work: The Norwegian Center for Technology and Art (Notam) Notam # Development for art projects (hardware, software, tech and artistic guidance) Communities / meetups (SC meetup among others) Studios / 3D sound / VR / Visuals Courses My practice # Computer music / livecoding Field recording 3D sound composition Sound environments Contact info # mail: mail@madskjeldgaard.

The default synth sound in SuperCollider is a cheesy old piano sound. If you have ever tried the event pattern examples in the documentation of SuperCollider or been in the process of testing some pattern specifics of your own, you will have heard this extremely unconvincing synthesizer: A nice alternative: A triangle wave synth with a low pass filter # Imagine a utopian world where the default cheese-piano-synth has been replaced by a nicer, kind of gameboy like synth.

Here you will find the material for the introductory workshop held at Notam, Oslo in late summer 2019. The slides may be used as a sort of cheatsheet as well as notes for remembering the topics covered: • An overview: What is SuperCollider and what can you do with it? • The design and architecture of SuperCollider • Language basics: syntax, variables, expressions and functions • Learning resources: How to proceed from here

Hedrot is an inexpensive head rotator that you can build yourself and attach to any pair of head phones, based on a small microcontroller (a Teensy) with an attached sensor board that measures your head’s rotation, pitch, tilt, etc. Using the Hedrot, you can monitor a binaural version of an ambisonic mix in a pair of headphones and be able to move your head around inside the sound field. In this tutorial we will cover how to set up the Hedrot application to send it’s sensor data via OSC to Reaper to rotate our ambisonic mix with our head movements.

In SuperCollider, one of the most common ways of making sounds is by first defining a sort of recipe for a UGEN patch in a SynthDef and then from that recipe produce Synths that make sounds. But when you write a SynthDef, the patch architecture cannot change after the definition (as opposed to changing arguments in the patch). This becomes annoying when working with UGens that want to know the exact number of channels used, eg.

One of the many powerful features of SuperCollider is it’s ability to render sounds offline. This is called Non-Realtime Synthesis (NRT). NRT is for example useful for fast, offline processing of sounds, doing sound analysis or rendering generative compositions. NRT works like this (normally): First you write a list of server OSC messages (stored in a Score usually) which will tell the (offline) server what to do at what point in time when you decide to render it.

We will assume that you already have SuperCollider running and that you have booted the server. Now you’d like to attach the GDB debugger to that process to see what happens when / if it crashes. Attach GDB to an already running scsynth process # First, we need to find the pid of the running process: ps -C scsynth -o pid h Then, we can use the number output from the command above to attach gdb: