Probably only of interest to Sonic Pi developers or anyone looking to
Dockerize similar audio applications that used jackd
.
This uses Vagrant and VirtualBox so you'll need plenty of spare RAM and disk space.
# (cd into this dir)
brew tap caskroom/cask
brew cask install virtualbox
brew cask install vagrant
Alternatively install vagrant from https://www.vagrantup.com/downloads.html
Then start a new terminal and run:
vagrant plugin install vagrant-docker-exec
vagrant up
The first time this will take something like 30 minutes as its building a docker host with 40Gb of disk and 2Gb of RAM, and then proceeding to build the docker container for Sonic Pi
To run the GUI you have to ssh into the running Docker instance with X11 forwarding like so:
vagrant ssh -- -Y
It will ask you for the password which is sonicpi
Once you're logged into the container, run the following to start the GUI:
developer@97fc279e468b:~$ /usr/src/app/app/gui/qt/rp-app-bin
To quit just ctrl+c the GUI process and log out of the SSH session with ctrl+d
Then to stop the Docker container just run
vagrant halt
to rebuild from the Docker file (don't worry about the error)
vagrant reload; vagrant up
and to shut down the Docker host image (the big Ubuntu VM that's actually running docker)
VAGRANT_VAGRANTFILE=DockerHostVagrantfile vagrant halt
With Docker we have a way to run sandboxed Sonic Pi code on a server for recording Gists in a sandbox and the like. It would also help in some development situations, mainly to test against a similar distro to Raspbian but on a faster machine than the RPi.
- Make beeps using sonic_pi gem
- Run sshd server
- Run the GUI via X11 and ssh forwarding
- Remove the
--privileged
flag so code is truly sandboxed
I had to do a lot of research just to figure out how to get Linux audio
to work in VirtualBox in the way I wanted. In that sense I think this repo
has made some progress in that area and I can see useful approaches in here for
other libraries that used jackd
like SuperCollider or Overtone. With that in mind,
heres a "reading list" of useful resources in Dockerizing audio applications in general.
- Running GUI apps with Docker
- Docker containers on the Desktop
- Docker Desktop
- Running an SSH service on Docker
- SuperCollider and jackd the easy way
- Top 5 wrong ways to fix your (Linux) audio
vagrant docker-exec -- sonic_pi "play 70"
For something slightly more fun try
vagrant docker-exec -- sonic_pi "$(wget -O - https://gist.githubusercontent.com/xavriley/ab0e7ad9b956c18af9f9/raw/68157657a9324e37fa8868a6137af6ace6952e30/wxg_piece.rb)"
# Listen to the output for a while
vagrant docker-exec -- sonic_pi "stop"
NB with that last command it's actually the OSX host that's downloading the gist, not the Docker container which is just being fed a string.
OSX and windows users can't use Docker directly. They need to run a virtual copy of
linux (a 'host' in docker terms) which then allows you to run the Docker containers
inside that. The popular solution for this is called boot2docker
and it's the one
all the tutorials will point you to if you have a Mac or Windows machine.
The problem is that boot2docker
runs a version of Linux that doesn't have any sound
drivers installed (It's a custom build of Tiny Core Linux for anyone who's curious...)
"No problem, I'll just
boot2docker ssh
and install the sound drivers using the package manager!"
Erm, yeah about that... This version of Tiny Core Linux renames the
kernel when building to boot2docker-4.0.4
or similar. The package
manager in Tiny Core Linux happens to use the kernel name to figure out
which packages to install - whether they need 32 or 64 bit - and the
main repo has no idea that boot2docker exists. That means you can't
actually use the package manager for many things with boot2docker
. On
top of that, any changes you made would get nuked on upgrade. That means
boot2docker
is a no-go until I can figure out how to do a build with
sound support (which I've started on
here)