Skip to content
Jeremy Weatherford edited this page Jun 18, 2015 · 4 revisions

Introduction

So you want to peek under the hood? Whether you're a seasoned hacker or a complete newbie, this overview will hopefully help you get the big picture of how Sonic Pi works its magic.

Moving pieces

GUI

You've interacted plenty with the user interface of Sonic Pi (the GUI). The GUI is written in C++ and uses the Qt framework, since that's a nice way to build cross-platform graphical applications (RasPi, Mac, Windows, and Linux at last count). However, the GUI doesn't do any of the heavy lifting of running code or making sound. Instead, it communicates with...

Server

The server is written in Ruby and starts in the background when Sonic Pi starts up. It's really the heart of Sonic Pi -- you could write a new front end for it and still have Sonic Pi (it's been done... Emacs is a popular choice for some reason!). The server is responsible for executing your song's code, and implements the vast array of functions that make Sonic Pi so well suited to making music.

The server is also home to the Time Machine, a truly amazing piece of technical wizardry that is responsible for keeping virtual time, allowing things to stay nicely musical even when different parts are moving at different speeds.

Finally, the server is a sort of zookeeper for SuperCollider, which is up next.

SuperCollider

SuperCollider is the audio synthesis engine that makes Sonic Pi sound good. The server keeps track of all the details of active notes, synthesizer parameters, FX, samples, and so on, and feeding all of that data to SuperCollider as it needs it via SC's documented OSC API (http://doc.sccode.org/Reference/Server-Command-Reference.html). It runs in the background as scsynth. SuperCollider is a third-party project with a life of its own, and is almost untouched by Sonic Pi developers. The only exception so far is on the Windows platform, where one patch to the network code is applied to keep it from aggravating the Windows Firewall.