Installation and Getting Started

Share your experiences/issues installing and getting started with Sonic Pi

I have some low powered ARMs (CHIPS https://getchip.com/pages/chip) that I like to use Sonic-Pi on for use on a small screen or headless and haven’t had many issues with the installation once I figured out a good process using the Raspbian binaries.

Sonic-Pi2 is fairly simple to install, only really requiring a later commit file to prevent sonic-pi from not using an existing running jackd session

Other than RAM issues on a device with 512MB with Sonic-Pi3 I haven’t had much issues using installing it, especially with gdebi
If you use Ansible I also created a playbook that installs Sonic-Pi 3 and also preps packages for Sonic-Pi-Tool compiling if you want to use it headless. It’s made for a CHIP but you can easily modify what you need to fit your target machine.
https://gist.github.com/Thndr/d8a9e424a259c2df62a610814de7b6b2


While the installation goes through relatively uneventful, getting started on the CHIPs is the awkward part. With the new UI it’s easier to make the window smaller to fit smaller resolutions, but that only alleviates some of the issues.

The UI doesn’t seem static and can change alignment when you close and open the program within small resolution environments. The toggling panels tend to distort existing layout, so even bringing up the preferences requires some work and a reboot of the software to adjust it back to optimum.

Due to the low powered nature of the CHIP and the increased requirements of Sonic-Pi 3 it requires a swap space, at least for GUI use(I have not tested without swap headless), as it gives a memory error and doesn’t boot the software.

The CHIP’s power itself is the same as a Raspi0 but I am unsure how well it runs (or doesn’t run) on Raspi0s to give a proper comparison if one platform is more optimized/works better than the other.
With my tests on the CHIP, when queuing code it tends to immediately have some thread delays and then starts going fine with occasionally an slight time offset. The more complex code/more actions queued, the more likely for thread death
I’ve tried in a completely headless environment running Sonic-Pi-Tool for command line control and it seemed to make no performance difference.

1 Like

Thanks for this feedback. It’s great to see people play with Sonic Pi on very low-powered devices such as the CHIP :slight_smile:

Whilst it’s true that Sonic Pi was originally designed for the Rasperry Pi 1 (which is even slower than the 0?!?) this focus has been a little bit lost now we support Windows, macOS and the majority of users on the Raspberry Pi platform are using Pi 2 or 3s. Unfortunately I have no resources to continue supporting low-powered devices myself but I welcome others with open arms.

If you have any specific ideas/patches/pull requests that can help improve Sonic Pi on small powered devices and/or devices with very low resolution screens, I’d be happy to receive them.

While I am unsure how much performance increase these would bring, I believe user control of what runs/how it runs would do a lot.

The GUI size itself is not much you can do with without specifically targeting the resolution from what I can see, and it may take a lot of work. I personally don’t mind if the GUI doesn’t work optimally as long as there’s a proper way to interact that does, such as command line support.

On low powered machines loading a GUI itself would take up RAM and processing power, so an option to load without a GUI would be nice. Sonic-Pi-Tool seems to do this and provides other command line support, but is a non-integrated way and doesn’t provide access to things like settings and preferences.

Command line support to do everything the GUI does would at least make it viable to use without the GUI, and also make it so you can use it on any device no matter the resolution since with tmux can be used in pane or window mode. (which is how I use Sonic-Pi-Tool at the moment)


I do not know how many resources would be saved in manually adjusting/tuning Sonic-Pi and what sort of servers it runs in the background, but I believe it’s worth a shot in at least optimizing it to run 1-4% better if we can add those increases up.

If there’s optimized/lower resource ways of running Jackd and the dependencies I’d love to give them a try, even if it’s compiling specific programs from their source.
I’m unsure if there’d be much of a performance difference compiling the Sonic-Pi3 package myself, but if there’s instructions on how to compile it to a .deb file (so I can backup and use that deb for re-installs) I’ll give that a shot to see if it runs even a little better.


Other than optimizing if I can’t get it running reasonably well I’ll just hope a future Raspi0-mkII // CHIPv2 is more powerful and can run Sonic-Pi3 with less issues, but I’m sure there’s some optimization that can go on before we reach that point.

A post was merged into an existing topic: How to trigger samples from external events

3 posts were split to a new topic: How to trigger samples from external events