Receiving OSC not working (properly)


I’ve compiled sonic-pi from git on ubuntu 16.04. This was relatively straightforward, although it needed a few outcomments. I’ll post about that later and probably in another category.

Currently I’m trying to get OSC reception working. So far it worked sometimes within spi (not very reliably) and never when sent from an external Python3 program on localhost. That external program (using python lilblo) successfully sends OSC back and forth between other OSC programs.

Sending OSC from sonic-pi to an external Python3 program works like a charm.

I’ve tried changing ports, switching OSC server on/off, switching the ‘Receive remote OSC messages’ option on/off.

Anyone got any hints as to what else I could try?


live_loop :foo do
  data = sync "/osc/trigger/prophet"
  synth :prophet, note: 70, cutoff: 100

and in another tab:

use_osc "localhost", 4559
osc "/trigger/prophet", 70


Do you see any incoming messages in the cue window? You shouldn’t need to write a single line of code to verify that messages are being correctly received :slight_smile:

Yes, OSC messages from external programs on localhost (Python, C++) give cues, e.g. like this:

/osc: [70]

I tried putting a single int in a message, or a blob with a single int or char or a blob containing multiple numbers and though I see the cues, they don’t seem to trigger the sync in the live_loop. Could be a matter of formatting… I know OSC is quite picky when it comes to getting the address and parameters right.
My expectations may be incorrect. Given the code above, would you expect the osc message “/trigger/prophet”,70 sent from within sonic-pi trigger the sync in the live_loop? That doesn’t even work in my case, even though I see cues of the exact same format as when they are received from external programs.

1 Like

One thing occurs to me. Looks like you are using 3.2dev. When checking the sync are you using something like

b = sync"/osc*/trigger/prophet"

It won’t work without the wild card * which allows for the ip and port stuff in the cues log ie the :

Brilliant, that works! Both internally and externally.
I’m indeed using 3.2dev, built from a git clone.

Thanks to both of you, Robin and Sam!

1 Like

I’ve done a pull request for a suggested update of the documentation for version 3.2dev onwards so that others aren’t caught out by this. Sam made this (breaking) change earlier in the year, I think so that he could differentiate osc messages coming from different ports on the same IP address. It adds additional filtering, though most users probably won’t need (or use) this. The bottom line is use /osc* rather than /osc (as in the previous documentation) and this will work for both 3.1 and 3.2dev onwards.

@marcg sorry for any confusion with the docs, but my advice is definitely to build a tagged release rather than master to avoid this kind of confusion in the future. Things are often in a state of flux in development and the documentation can easily get out of sync :slight_smile:

Hi @marcg,

I’d be very grateful for that 'cause currently I am also working with Ubuntu 16.04 (Mint). I recently tried to compile but had some issues (I can’t remember exactly, what it was).


Hi Martin,

actually building from source was quite straightforward, but it failed towards the end of the build script when it started complaining about missing a scintilla shared lib and somewhat later compilation broke on some aubio functions.

The scintilla problem was due to a duplicate mention of libqt5scintilla2-dev, I think this has already been fixed upstream.

The most prominent changes I made were outcommenting some lines in ‘app/server/ruby/vendor/ruby-aubio-prerelease/lib/aubio/api.rb’:

#attach_function :aubio_tempo_get_silence, [:pointer], :float
#attach_function :aubio_tempo_get_threshold, [:pointer], :float
#attach_function :aubio_onset_get_silence, [:pointer], :float

as compilation failed on these. It didn’t seem to have negative effects so far…

I also removed the ‘-y’ switch from apt-get in ‘build-ubuntu-app’ to keep control of things. I made sure all dependencies were met and checked some shared libs.

I’ve made a snapshot of the code that works for me:
and left out the folders etc, bin and .git to save space. You can try cloning the sonic-pi repository again, copy my folders over it and see if it builds on your system, or don’t rebuild and just use the app/gui/qt/sonic-pi executable.

Hope this helps you forward in some way.


No problem Sam, I appreciate your help. I’ll use a tagged release next time or dig into the code.
After Martin Butz’s presentation last week at Sonoj Convention I’ve been playing with sonic-pi quite a bit.
I’m impressed and seriously consider using it for some of my programming classes in the near future.


1 Like

Hi Marc,

thanks a lot for writing that down. I probably will have time next weekend and will try to do another build of the latest version.


PS.: Downloaded the snapshot…

Hi Marc,

ok, after installing a few missing programs (such as samplerate) and 2 more compilations the build-ubuntu-app-started compilation complains about lqscintilla:

/usr/bin/ld: cannot find -lqscintilla2_qt5
collect2: error: ld returned 1 exit status
Makefile:232: die Regel für Ziel „sonic-pi“ scheiterte

build-ubuntu-app says:

#cd $SP_APP_SRC/../../../../
#wget ''
#tar -xf QScintilla_gpl-2.9.2.tar.gz
#cd QScintilla_gpl-2.9.2/Qt4Qt5/
#sudo make install

But I am not sure if this is what I do. Probably a symbolic link would do it, because it seems to me I have qscintilly installed. Do you have any recommendations at this point (if I can bother you with that)?


Have a look in the Makefile Martin, there is a line with LIBS. In the version I had, the libscintilla library was mentioned twice under slightly different names. I removed -lqscintilla2_qt5 and kept -lqt5scintilla2, resulting in:

LIBS          = $(SUBLIBS) -L/usr/X11R6/lib64 -lrt -L/lib -lqwt-qt5 -L/usr/lib/x86_64-linux-gnu -lqt5scintilla2 -lQt5OpenGL -lQt5Svg -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Concurrent -lQt5Network -lQt5Core -lGL -lpthread 

Then type make again. I hope this helps.


Hi Marc,

after a slight confusion (which I seem to have resolved by cloning the files rather than downloading a *.zip file) it seems to have worked.

I had a non-working midi system. The osmid log told me:

sh: 1: exec: /home/[my_path]/app/server/native/osmid/m2o: not found

So I moved the osmid folder from:


to the path referenced in the log (without /linux/). Just in case someone encounters the same issue.

So far everything seems to work, but I have not yet checked properly.

Thanks for your assistance!