Building SP3.2dev from source on a Pi4 NOW OBSOLETE

This version will not work with the 3.2.0 release source.

UPDATED 2nd Feb 2020
Problems with gem files build are now sorted, and rugged does not have to be treated separately. Instead compile_extensions.rb can be run without modification

An error in the line
cp utils/ruby_help.tmpl ruby_help.h
has been corrected to
cp utils/ruby_help.tmpl utils/ruby_help.h

Further changes in the Sonic Pi source code which is currently undergoing some fairly radical changes means two changes have to be made to let it build using the method I have used below rather than tje cmake method under development.

These are covered in two files that need to be amended are described in this issue posted on the github site.
Since that issue was posted some further commits have moved the relevant line numbers, but you should be able to locate them without too much difficulty still.
the scope.cpp line number after commit #72cd59 is still 199, but the line to change in mainwindow.cpp has moved to line 1041

The original article follows, with the modifications listed here incorporated

At present the Raspbian Buster distribution which is necessary to run a Pi4 ships with a very old version of Sonic Pi (2.10). For those used to using version 3.0.1 on the earlier Rasbian Stretch distro on earlier Pi versions this is a frustration.
In time a new .deb file may be developed for Buster, and there has been correspondence elsewhere about the problems of this happening.

In the meantime, for those who are prepared to build Sonic Pi 3.2dev from source this is perfectly possible, and the performance of this version on a Pi4 makes it well worth the effort. However please note that this is a development version which does have some glitches still to be ironed out, and as such it is NOT a build that can be supported by Sam Aaron, (or indeed by myself), although there are probably those on this forum who may be able to help if necessary.
I have produced some instructions which will enable you to build Sonic Pi3.2dev on a pristine install of Buster release date 2019-07-10 with

sudo apt update
sudo apt upgrade


I built it on a 4Gb RAM version. The final build will certainly work on 1 and 2Gb machines, but on the former you may have to temporarily increase the swap file size. Seethis article for details. You can swap it back again afterwards.
The whole build process takes about 30 minutes to complete.
It is designed to coexist with the installed Sonic Pi version, and it probably best to leave this installed. If you remove it, you have to reinstall two packages to get the 3.2 version running.
Some of the instructions can merely be copied and pasted into a terminal window. However there are a couple of bits that need to be manually completed involving use of a text editor.
Start a terminal window in the Pi user home folder, then copy and paste in the section below, which will:

  • install extra packages required
  • create a src folder and download sonic pi source files into it.
  • add osmid source files to the src folder
  • build the m2o and o2m binaries in osmid
  • install the binaries
  • build the two erlang files from osc.erl and pi_server.erl
#now install extra packages needed to build Sonic Pi
sudo apt-get install -y \
     g++ ruby ruby-dev pkg-config git build-essential libjack-jackd2-dev \
     libsndfile1-dev libasound2-dev libavahi-client-dev libicu-dev \
     libreadline6-dev libfftw3-dev libxt-dev libudev-dev cmake libboost-dev \
     libqwt-qt5-dev libqt5scintilla2-dev libqt5svg5-dev qt5-qmake qt5-default \
     qttools5-dev qttools5-dev-tools qtdeclarative5-dev libqt5webkit5-dev \
     qtpositioning5-dev libqt5sensors5-dev libqt5opengl5-dev qtmultimedia5-dev libffi-dev \
     curl python erlang-base libssl-dev libaubio5 supercollider-server

#create folder src in Pi home folder
mkdir -p ~/src
cd src
#install sonic-pi source (latest)
git clone

#install source for osmid, and build m2o and o2m     
git clone || true
cd osmid
mkdir -p build
cd build
cmake ..

#add installation folder in Sonic Pi
mkdir -p ../../sonic-pi/app/server/native/osmid/
#copy over the two binary images
cp m2o ../../sonic-pi/app/server/native/osmid/
cp o2m ../../sonic-pi/app/server/native/osmid/

There is an existing bug in the source-files for SP concerning the pi_server.erl file. In  commit dedc9ea6cfbf6e8c6d02e48196c5cb23c93e0b55 on 22nd October 2017 Erlang - tech scheduler to only listen on loopback network (This stops the Erlang process from triggering firewall warnings on Windows) Sam prevented the erlang schedular in listening to entries other than from the local host. This was to solve a problem with the Windows install. Unfortunately it also had the side effect of preventing Sonic Pi from sending OSC messages to external IP addresses. Of course, on a non windows matching this is not a problem, and you can revert this commit and rebuild the modified pi_server.erl file and it will then be able to send OSC messages to external IP addresses. The change required is in line 69 which reads
` {ok, Socket} = gen_udp:open(Port, [binary, {ip, loopback}]),`
change it to read
` {ok, Socket} = gen_udp:open(Port, [binary]),`
and resave the file.

Now is also a good time to alter the two files scope.cpp and mainwindow.cpp as detailed in update 3 described above

#build the two erlang beam files
cd ~/src/sonic-pi/app/server/erlang
erlc osc.erl
erlc pi_server.erl

#The rest of the build process is carried out in a terminal window from the qt folder

cd ~/src/sonic-pi/app/gui/qt
#compile some vendor gems
#note this also creates the folder ../../server/ruby/rb-native/2.5.0
#you will notice several warnings during this process but that is normal
#it will also take some time to complete

#now start building the documentation
#first the translation files
../../server/ruby/bin/i18n-tool.rb -t

#prepare a fresh header for the help file compilation
cp utils/ruby_help.tmpl utils/ruby_help.h
#populate the header file with qt-doc.rb
../../server/ruby/bin/qt-doc.rb -o utils/ruby_help.h

#now complete the preparation of completed translation files
#listed in the file

#prepare the Makefile using qmake

#do the compilation of sonic pi
make #this takes quite a bit of time

Hopefully at this stage you have completd a working Sonic Pi3.2dev
To test it, in your terminal window type


You should see the sonic pi logo in the terminal window and a splash screen will open.
After about 20 seconds you should see the main Sonic Pi window opening.

for a clean exit right click the Sonic Pi icon in the taskbar and choose Close Window.
Note although the window will close immediately the app takes about 19 seconds seconds to completely close down, so don’t try to restart it immediately.

Further work, to add an icon to start Sonic Pi3.2 from the maim menu.
It is easy to add a second SOnic Pi icon to the application menu as follows:
from a terminal type:

sudo cp /usr/share/pixmaps/sonic-pi.png /usr/share/pixmaps/sonic-pi3.2.png
# edit the new desktop file using nano:
sudo nano /usr/share/applications/sonic-pi3.2.desktop

Change the contents of the editor window to the version shown below. Essentially adding 3.2 three times

[Desktop Entry]
Name=Sonic Pi 3.2
Comment=Learn programming and computer science while creating music

Type ctrl+X followed by Y return to exit, saving the file with its existing name
(Note I used a duplicate icon, in case the original Sonic Pi is uninstalled so tha the second icon remains.)

Now generate a launcher file to place in /usr/bin
paste the folliowng

cd /usr/bin
sudo nano sonic-pi3.2

Tyoe ctrrl+X then Y return to exit
Finally make the file executable:

sudo chmod +x /usr/bin/sonic-pi3.2

You should now find a Sonic Pi 3.2 icon in the Applications Menu Programming Section underneath the original Sonic Pi icon. Clicking it should launch Sonic Pi 3.;2dev

Note if you want to move the sonic-pi folder in the src somewhere else, having completed the build then you can do so. You just have to amend the path in the sonic-pi3.2 file in the section above to suit. (change the /home/pi/src/sonic-pi/bin/sonic-pi to give an absolute path to the new location)

Some notes on the installation

This is a development version, and it has one or two known bugs/problems

The transparency slider in the Preferences panel is currently visible, but has no effect. IF it is not possible to get it working with a Pi, then it will be removed before the final version.

Even though it is ticked as enabled in the IO prefs section, OSC messages don’t work
until you disable and then re-enable the OSC Server

It is possible to run Sonic Pi using an externally setup jack server using QjackCtl.
This is of great use if you want to connect inputs from a sound card like PiSound,
which can also work with reduced latency by adjusting the connection parameters.
It can also let you connect the audio output of Qsynth or Helm synths
running on your Pi directly to Sonic Pi, even if you don’t have a sound card.
I will detail this later in a separate article.

Note Sonic Pi does NOT stop the current jackd when it quits, (in case you are using an external version).
Consequently you must issue killall jackd if you have started Sonic Pi with the internal call to jackd BEFORE you can subseqeuntly use QjackCtl.
qjackctl IS already installed on Buster but is hidden on the Applications Menu.
To enable it, select Main Menu Editor from the Preferences Section, navigate to the Sound & Visual section, and tick QjaclCtl to enable it.

If you uninstall the original Sonic Pi (ver 2.10) (which I don’t recommend) then it will also remove ruby and supercollider-server packages.
In this case you will have to reinstall them using
sudo apt install ruby supercollider-server
for Sonic Pi3.2dev to work.

Although this install has been created on a Pi4, the SD card can be transferred to a Pi3B+where it will work quite happily. It should also build on this Pi model, although it may take a lot longer, and I suspect you may have to temporarily increase the swap file size as mentioned at the beginning of this post.

Occasionally things can go wrong and Sonic Pi doesn’t exit cleanly and clean up it various components. One way to do this is to reboot the machine. More easily in ` terminal:

killall m2o
killall o2m
killall beam.smp
killall scsynth
killall ruby

should clobber everything. (You will get not found messages for thse that are already closed)

Transporting Sonic Pi3.2dev to a different SD card
Having built Sonic Pi3.2 it is possible to slim down a copy the final folder, and then move this to another Raspbian Buster SD card. With the addition of three packages, and adding the desktop files this will then work there, without having to build it again. At a later date I will give fuller detains plus some scripts to automate the process.

I hope that this post will be useful. I would welcome feedback on its use, so that it can be amended if necessary.


OK. I’m going to give this a go now. I don’t have a clean install, but I did update and upgrade everything the other day.

I did the install as described above and everything worked fine. The only variation I made to the process was to use vi for editing in the terminal :slight_smile:

I haven’t added a main menu (in your text you say ‘maim menu’ :slight_smile:) icon yet. I’m satisfied that it’s running.

Admittedly, in terms of testing, I only went as far as running a fairly basic live_loop. But, that worked fine.

Glad you’ve got it going. Have fun with it!

1 Like

Good evening Mr @robin.newman !

I just want to thank you so much for this step by step tutorial to build the latest dev version of Sonic Pi on raspian Buster with the latest version of raspberrypi 4.

It works like a charm and sure you make great great job to promote Sonic Pi around the world.
When i follow your tutorial, i am always certain it will work !
I do appreciate your comments as every good teacher should write.


At this moment, Sonic PI is playing via the audio jack.
Next steps for me is to manage to send the sound through my Focusrite Scarlett 2i2 usb audio interface. Youtube is playing well via the focusrite so how tell Spi to do the same ?

Best regards

First right click the loudspeaker icon top right and chose your focusrite as the output device. (Alternatively do so using main menu->preferences->audio device settings)
Then go to Main Menu->preferences->Main Menu Editor and navigate to sound & video. Click the box beside QjackCtl to enable it.
Then start up QjackCtl from the Main Menu->Sound &Video section.

When it starts, click on Setup and set the interface to use your Focusrite as the default device. Click the Advanced settings and chose focusrite for the input and output devices. You should probably choose in the parameters section sample rate of 41000 or 48000 and frames /period 1024
and periods/buffer of 2 or 3. Save the settings and stop and restart Jack Audio Connection. Then start Sonic Pi which should pick up these parameters and use the connection specified by QtjackCtl.
You can fine tune the parameters in QjackCtl but remember whenever you change them and restart jack you must restart Sonic Pi to pick up the changed parameters. it always starts with the current default audio settings.
Generally in fine tuning the settings, , increasing the sample rate helps, as does reducing the periods/buffer 2 rather than three. You can see the resultant latency dislayed. (lower is better). If you go too far you will get clcik and scratchyt noises from Sonic Pi.

Good evening,

So eveything is working fine with Focusrite Scarlett 2i2 under RaspberryPi 4 with raspian buster :slight_smile:

Now it’s time to test it seriously.

To test Open Sound Control, i test with this code.
First do as mentionned by @robin.newman :

# Open Sound Control in Sonic Pi
# Sonic Pi v3.2.0-dev-6614a on Raspberry Pi 4B 2Go - ip:
# Raspbian buster
# With the help of Robin Newman
# 02-10-2019.
# message sent by sonic pi himself or by [hundredrabbits] Orca or AIOI
# Watch at time values

use_osc "",4560

live_loop :from_SP_send_c do
  osc "/c",:e2, 1
  sleep 4

live_loop :from_SP_send_b do
  osc "/b", 0, [1,2].tick
  sleep 1

live_loop :from_SP_send_e do
  osc "/e", 1
  sleep 8

live_loop :loop_e do
  b = sync "/osc*/e"
  sample :guit_e_fifths, amp:b[0]

live_loop :loop_b do
  truc = sync "/osc*/b"
  sample :bd_fat, attack: truc[0], amp: truc[1]

live_loop :loop_c do
  use_synth :saw
  c = sync "/osc*/c"
  puts c
  play c[0], sustain: c[1]

# to control sound output
live_loop :bip do
  # piano does not work
  use_synth :tri
  play :B3, sustain: 0.5, amp: 0.5
  sleep 4

Well the time values into log seems to be in late due to sample loading ?

{run: 95, time: 5.0, thread: :live_loop_from_SP_send_b}
 └─ OSC ->, 4560, /b, [0, 2]
{run: 95, time: 5.0046, thread: :live_loop_loop_b}
 ├─ synced "/osc*/b" 
 ├─ sample "~/srcInstallSpi/sonic-pi/etc/samples",
 │           "bd_fat.flac", {attack: 0, amp: 2}
 └─ sync "/osc*/b"
{run: 95, time: 6.0, thread: :live_loop_from_SP_send_b}
 └─ OSC ->, 4560, /b, [0, 1]
{run: 95, time: 6.0046, thread: :live_loop_loop_b}
 ├─ synced "/osc*/b" 
 ├─ sample "~/srcInstallSpi/sonic-pi/etc/samples",
 │           "bd_fat.flac", {attack: 0, amp: 1}
 └─ sync "/osc*/b"

The synth piano does not work.

I added an addendum extra bit recently to the instructions which explains why external osc messages are not working and how you can alter the file pi_server.erl to correct it and then rebuild pi_server.beam (this is if you want to send Oscar messages from sonic Pi to an external computer address. Works ok sending to the local machine.

Time problems. Put use_real_time Into live loops that are syncing to incoming osc messages, otherwise their response is delayed by the current sched ahead time.

Piano synth should work unless you are using an old version of scsynth and its plugins. Make sure you have done sudo apt update and sudo apt upgrade before building sp as the initial version was updated on raspbian buster.

Thanks so much for this - really good to get sonic pi working again on a pi 4. Very helpful instructions.

1 Like

Glad it worked for you. Enjoy sp3.2dev
There are one or two issues with it but nothing major.
EG can’t see dialog entries clearly for load/save when using darkmode
Visuals transparency doesn’t work on Pi (should probably still be disabled)
Be aware that OSC commands are received on port 4560 not 4559 now
Also a received osc cue from a message such as osc “/note”,60 will generate a cue in the log like
/osc: [60]
and will require you to use
n = sync “/osc*/note”
The * will match the new data giving ip address and port. Using this format will work with both version 3.1 and 3.2dev

1 Like