Hi everyone, I hope your well thanks for all your help so far.
I’m running the latest bata version of sonic pi on Mac os10 high Sierra I’m experiencing a multitude of issues with my installation so I need to completely reinstall the bata version of sonic pi from scratch. Please could someone explain to me how to do this? Thanks very much for all your help, kind regards trey.
Hi there.
I can sympathise having spent a considerable amount of time getting this to work.
I don’t at present have a nicely produced list of what to do but I can give you some important pointers.
First brew problems. This has a nasty habit of updating everything, and in particular in the summer it updated the boost libraries version (which is used by Sonic Pi. This is critical because SuperCollider is also built using boost, and it is important that it uses the same version. The best way out of this is to build SuperCollider from source. If you do so, you have two options. Either use the built in boost library in the SC source code, OR switch it to build with the system boost.
The lines you need to add (for the former) are:
LIBS += -L/Users/rbn/srcNew/Supercollider/external_libraries/boost/libs
INCLUDEPATH += /Users/rbn/srcNew/Supercollider/external_libraries/boost/
DEPENDPATH += /Users/rbn/srcNew/Supercollider/external_libraries/boost/
(adjust for your user name and src location)
You add these after the LIBS += -lqscintilla2_qt5 line in the # Mac OS X only section. Otherwise there is a flag when building SC which you set to use the system boost when building (I can’t remember it offhand but I think it was -DSYSTEM_BOOST=ON). However it is probably better to use the built in boost library for SC as it has some tweaks relevant to SC.
Secondly Ruby version. I use rvm to manage my Ruby versions installed. Sam Aaaron tells me he is currently building with Ruby 2.6.4 and I used this also for my most recent build (I use 2.5 when building on a Raspberry Pi)
EDIT
Don’t forget to add in a slft link to your ruby binary:
from the qt folder do
mkdir -p ../../server/native/ruby/bin
ln -s `which ruby` ../../server/native/ruby/bin/ruby
note the previous osx in the above path is now dropped
END EDIT
I have found problems in building some of the Vendor GEM files with compile-extensions.rb. In particular Rugged (on Raspberry Pi) and ffi which has very recently been updated to version 1.11.1
My solution is to do a gem install using ruby install ffi -v ="1.11.1" (note do not use sudo on your Mac). I then copy the installed gem to the vendor folder in SP from $GEM_HOME"/gems replacing the copy in the Sonic Pi source. I then modify the Sonic Pi compile-extensions.rb) utility so that it does not attempt to build ffi, and when it has finished running I copy the ffi_c.bundle from the ffi/ext/ffi_cfolder to therb-native/2.6.0` folder to join the other bundle files compile-extensions as produced for other vendor gems. It is a bit of rigmarole, but you only have to do it when vendor gems (infrequently change) Note running compile-extensions.rb wipes out the contents of your 2.6.0 folder, so you need to copy in the ffi bundle each time you have run it.
There have been a lot of changes since about June to the layout of Sonic PI files in the distribution, which has invalidated many previous build instructions. However much remains the same:
The native folder contains osmid and erlang subfolders as before and you build m2o and o2m and put them in the osmid folder as previously.
Brew rears its head again, and you should not use the brew installed erlang, as the version has been bumped and there is an error if you try and build the two beam files erl.beam and pi_server.beam. Instead copy the erlang folder from a version 3.1 sonic-pi install and put it into your new build. Also copy the erlang folder that resides in the server folder from a 3.1 install or from the patreon 3.2b build if you have access to that (if not become a patreon supporter 
) So basically ALL the erlang stuff should be installed from an existing Sonic Pi version. (You can still build with a system erlang on Raspberry Pi or linux as the current versions are OK).
The supercollider folder in the native folder should contain the scsynth than you have built (copied there) and also the plugins in a folder, again copied from your SC build. Also, as for previous bullds you should have a link in the top level native folder pointing to supercollider/scsynth.
You can use the brew installed qwt and qscintilla2
In each case you should copy their data/mkspecs/features/* to
/usr/local/opt/qt5/mkspecs/features so that they are integrated to the qt install.
Once you have this stuff in place move on to the Documentation build.
as previously use a terminal from the qt folder :
../../server/ruby/bin/i18n-tool.rb -t
followed by
cp utils/ruby_help.tmpl utils/ruby_help.h
to set up an empty header file (note this is in a new location in the utils folder)
followed by
../../server/ruby/bin/qt-doc.rb -h utils/ruby_help.h
to build the ruby_help.h file (again note the new location)
Now as before use
/usr/local/opt/qt5/bin/lrelease SonicPi.pro
This references the lrelease binary from the installed qt5
followed by
/usr/local/opt/qt5/qmake SonicPi.pro
and finally make
When this has finished you need to add links to the etc app and server folders inside the Sonic Pi.app bundle
a very recent commit has moved their location to the Resources folder inside the bundle, to reflect Apple guidelines.
cd Sonic\ Pi.app/Contents/Resources
ln -s ../../../../../../etc ./
ln -s ../../../../../../app ./
ln -s ../../../../../../app/server ./
This should now get you a working Sonic Pi 3.2dev It needs further work to become standalone, but I rarely do this, but use as a static working install, which can easily be updated. Generally on rebuilds you would now start at the Documentation stage as the vendor stuff and osmid, SC, erlang are unlikely to change.
I hope the above is not too rambling, and may be of use to you.
Also the latest mac-build-app file is useful to refer to, although not complete enough I think. Also note Sam moves the Sonic\ PI.app to a build folder so the soft links to etc, app and server are different to mine.
Read alongside the current build-osx-sierra-app file, and amend according to what I have described above.
1 Like
Hi @soundwarrior,
if you’re using the beta downloaded from the website, you should be able to remove it by deleting the app from the /Applications folder.
For completeness, you might also want to remove the ~/.sonic-pi folder which contains all the current state of the buffers and a few other settings.
Finally, you can delete the Qt preference files (which store the state of the GUI options) in ~/Library/Preferences/.net.sonic-pi*
@robin.newman’s instructions assume that you built Sonic Pi manually which I don’t think is the case for you
building sonic pi from scratch is way to complex for me where is the first folder you mentioned located please? thanks for your help
I think the latest beta version downloaded as a zipped file, which you extract by double clicking. Normally the resultant file would be dragged to the Mac Applications folder and run from there, but you may have left yours in the downloads folder or put it somewhere else. When you have found it (you can use the Mac Spotlight Search to find it if you cant remember where it is: open Spotlight from the top menu bar, enter Sonic-Pi, scroll downwards and select Show In Finder, then scroll down any resulting list. When you have found it move it to trash to delete.
The second folder Sam Aaron mentioned holds information related to Sonic Pi and is automatically generated the first time SP is run, and updated on each subsequent run. It is normally a hidden folder ( the name starts with a . so it doesn’t usually show up in the Finder.
You could remove it from a terminal window. (Just type Terminal + return into a Spotlght Search window).
You can then type
ls ~/.sonic-pi (+return)
to view its contents and
rm -fR ~/.sonic-pi (+return)
to completely remove it. WARNING carefully check the second command so it doesn’t delete the wrong thing by mistake.
If you download the beta copy again you can then extract it and try again with the new copy. NB for the first run you will have to right-click it and select open and assent to the Mac running it. Subsequently you can double click it as usual.