# Receiving OSC not working (properly)

**URL:** <https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643>\
**Category:** Support, Help & Resources\
**Created:** [October 31, 2018, 6:57pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643 "2018-10-31T18:57:13Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![marcg](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/marcg/32/771_2.png) [@marcg](https://in-thread.sonic-pi.net/u/marcg)\
**Post date:** [October 31, 2018, 6:57pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/1 "2018-10-31T18:57:13Z")

</div>

Hi,

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?

spi-code:

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

```

and in another tab:

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

```

Thx,  
Marc

---

<div class="post-metadata">

**Author:** ![samaaron](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/samaaron/32/7_2.png) [@samaaron](https://in-thread.sonic-pi.net/u/samaaron)\
**Post date:** [November 1, 2018, 6:26pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/2 "2018-11-01T18:26:41Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![marcg](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/marcg/32/771_2.png) [@marcg](https://in-thread.sonic-pi.net/u/marcg)\
**Post date:** [November 1, 2018, 9:25pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/3 "2018-11-01T21:25:23Z")

</div>

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

```ruby
/osc:127.0.0.1:4560/trigger/prophet [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.

---

<div class="post-metadata">

**Author:** ![robin.newman](https://avatars.discourse-cdn.com/v4/letter/r/76d3ee/32.png) [@robin.newman](https://in-thread.sonic-pi.net/u/robin.newman)\
**Post date:** [November 1, 2018, 10:06pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/4 "2018-11-01T22:06:28Z")

</div>

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

```ruby
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 :127.0.0.1:4560

---

<div class="post-metadata">

**Author:** ![marcg](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/marcg/32/771_2.png) [@marcg](https://in-thread.sonic-pi.net/u/marcg)\
**Post date:** [November 1, 2018, 10:58pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/5 "2018-11-01T22:58:29Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![robin.newman](https://avatars.discourse-cdn.com/v4/letter/r/76d3ee/32.png) [@robin.newman](https://in-thread.sonic-pi.net/u/robin.newman)\
**Post date:** [November 2, 2018, 11:34am UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/6 "2018-11-02T11:34:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![samaaron](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/samaaron/32/7_2.png) [@samaaron](https://in-thread.sonic-pi.net/u/samaaron)\
**Post date:** [November 3, 2018, 8:25am UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/7 "2018-11-03T08:25:31Z")

</div>

@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 🙂

---

<div class="post-metadata">

**Author:** ![Martin](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/martin/32/157_2.png) [@Martin](https://in-thread.sonic-pi.net/u/Martin)\
**Post date:** [November 3, 2018, 9:51am UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/8 "2018-11-03T09:51:34Z")

</div>

Hi @marcg,

> [@marcg](#):
>
> 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.

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).

Martin

---

<div class="post-metadata">

**Author:** ![marcg](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/marcg/32/771_2.png) [@marcg](https://in-thread.sonic-pi.net/u/marcg)\
**Post date:** [November 5, 2018, 12:03pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/9 "2018-11-05T12:03:56Z")

</div>

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’:

```ruby
#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: [https://www.dinkum.nl/martin\_sho5Rae7Af8kae3i](https://www.dinkum.nl/martin_sho5Rae7Af8kae3i)  
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.

Cheers,  
Marc

---

<div class="post-metadata">

**Author:** ![marcg](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/marcg/32/771_2.png) [@marcg](https://in-thread.sonic-pi.net/u/marcg)\
**Post date:** [November 5, 2018, 1:03pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/10 "2018-11-05T13:03:44Z")

</div>

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.

Cheers,  
Marc

---

<div class="post-metadata">

**Author:** ![Martin](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/martin/32/157_2.png) [@Martin](https://in-thread.sonic-pi.net/u/Martin)\
**Post date:** [November 5, 2018, 7:11pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/11 "2018-11-05T19:11:55Z")

</div>

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.

Martin

PS.: Downloaded the snapshot…

---

<div class="post-metadata">

**Author:** ![Martin](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/martin/32/157_2.png) [@Martin](https://in-thread.sonic-pi.net/u/Martin)\
**Post date:** [November 11, 2018, 2:29pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/12 "2018-11-11T14:29:03Z")

</div>

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`:

```ruby
/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:

```ruby
### IF YOU HAVE PROBLEMS WITH qscintilla2
#cd $SP_APP_SRC/../../../../
#wget 'http://sourceforge.net/projects/pyqt/files/QScintilla2/QScintilla-2.9.2/QScintilla_gpl-2.9.2.tar.gz'
#tar -xf QScintilla_gpl-2.9.2.tar.gz
#cd QScintilla_gpl-2.9.2/Qt4Qt5/
#/usr/lib/x86_64-linux-gnu/qt5/bin/qmake qscintilla.pro
#make
#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)?

Martin

---

<div class="post-metadata">

**Author:** ![marcg](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/marcg/32/771_2.png) [@marcg](https://in-thread.sonic-pi.net/u/marcg)\
**Post date:** [November 11, 2018, 4:47pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/13 "2018-11-11T16:47:43Z")

</div>

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:

```ruby
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.

Marc

---

<div class="post-metadata">

**Author:** ![Martin](https://dub1.discourse-cdn.com/flex017/user_avatar/in-thread.sonic-pi.net/martin/32/157_2.png) [@Martin](https://in-thread.sonic-pi.net/u/Martin)\
**Post date:** [November 11, 2018, 5:53pm UTC](https://in-thread.sonic-pi.net/t/receiving-osc-not-working-properly/1643/14 "2018-11-11T17:53:53Z")

</div>

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:

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

```

So I moved the osmid folder from:

```ruby
 /home/[my_path]/app/server/native/linux/osmid/

```

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!

Martin