Sonic Pi, Processing and OSC

Thanks so much for the help!
But I’m having the same issue with your code, no signals are reaching the processing sketch, so annoying!

What platform/OS are you working on? Is your processing sketch on the same machine as Sonic Pi?
I’ll try a few experiments here, and check out if my code is still OK .

I’m on Archlinux and everything is running on the same machine. Thanks for trying!

Tried on another computer running windows, your code worked fine, so there’s something weird going on with my linux laptop, I’m no networking wizard but I’m guessing the problem may be there, have to investigate further.

I’ve experimented using the oscdump utility from the liblo package, and nothing shows up there either. Could there be something going with the Sonic-Pi that’s in the arch repositories?

What version of Sonic Pi is it?

It’s 3.1.0-7, installed from https://www.archlinux.org/packages/community/x86_64/sonic-pi/

Try running this test code. It sends data via OSC from Sonic Pi back to itself

use_osc "localhost",4559
live_loop :sendtest do
  d=[0.2,0.4].choose
  osc "/play",rrand_i(48,84),d
  sleep d
end

live_loop :receivetest do
  n,d = sync "/osc*/play"
  play n,release: d
end

That should check if OSC messages are being sent and received.

Not getting any sound over here

can you see any osc cues in the cue log?
IF not try clicking the tick beside enable OSC server in the prefs IO section.
Turn it off then on again and rerun the program.
IF it was Off already then that is probably the problem.

If the program doesn’t work looks like there is something wrong with your SP

I’ve tried turning it off and on again :slight_smile:
Maybe I’ll have a go at compiling the whole thing from source and see if that helps, I’m no linux wizard, but I’ll try!
Thanks again for trying to help me out!

IF you build latest 3.2dev then beware of several changes to port allocation, and also there IS a bug there still to be sorted where you DO have to turn OSC server off then on again before OSC messages work, by clicking the box in the IO preferences.
Also Sonic Pi receives messages on port 4560 not 4559 as in version 3.1
Also received cues coming in to sonic pi contain additional info

if you send “/play”,60 the cue you receive in the cue log looks like /osc:127.0.0.1:4561/play [60]
To sync this you can use

n = sync "osc*/play"

n=sync "osc/play" will NOT match

The * matches all the extra stuff which you don’t normally need.

A final change is that some other ports are dynamically allocated, including the server Listen port which receives osc commands from the gui to Sonic Pi. The actual value allocated is shown in the server-output.log Since this port is used by programs like the sonic-pi-cli command they will be broken.
I discussed this, and the post of an updated version here

This whole compiling business is way above my level of computer wizardry, been hacking away at error messages and finally got to the point where I’m going to issue the final make command, but it fails with some deprecated declaration.

Think I need a pause from this to keep the few bits of sanity I have left.

1 Like

Hi @andars,

I am really sympathising with your last post. I sometimes also just need a break. Technology can be very frustrating and tiring - sometimes… then again joyful bliss about things that finally work …

You are writing, that you can receive OSC in SP but you can’t send OSC messages, right? Did you try to compile the erlang files? Just a shot in the dark but the symptoms described in this thread match your description.

The problem is I haven’t built the version I’m running myself, it’s installed from the arch repositories. I’m guessing the compilation of the erlang files would only have effect if I compiled it from source myself?

Well, yes, might be true. I don’t know enough about it…

But you could try just to compile the Erlang part:

  • Download osmid: https://github.com/llloret/osmid
  • Follow the build instructions in …/osmid-master/INSTALL.md
  • Copy files m2o and o2m to [SonicPiInstallation]/app/server/native/linux/osmid] (you will have to check were these files lie in your current installation; I am not sure that this information is still right)

This might be worth a try … once you’ll have paused a bit :wink:

1 Like

I can sympathise with how you feel. Recently I spent several weeks trying to debug my build of 3.2dev on a Mac. Very frustrating, but I got there in the end. Turned out that the boost library I was using had been upgraded! Once I adjusted it to be the same as the one used in SuperCollider all was well again.

One word of caution about doing your own build on the latest 3.2dev source. recently there has been a revision of the layout of files in the gui/qt folder. Make sure you base your build on a recipe which is up to date. The post I did recently about building on a Raspberry Pi4 gives an indication of what is involved, although it would have to be tweaked for archlinux.

1 Like

I managed to compile it! And it sends OSC!
had to disable warnings to get past some deprecated QSignalmapper stuff, but it works!

2 Likes

Well done! Have fun with it now.

A thought that had been lurking in the back of my mind surfaced today when I had problems using a project a wrote some time ago in which Sonic Pi had to receive an OSC message from an external IP address.

Sam Aaron committed a change to the pi_server.erl file which I think was to prevent a problem with the windows install of SP. Unfortunately it also clobbered the arrival of external OSC messages.
I reverted the commit on my version of SP here, and forgot about it, until I tried with a recent build which had NOT had it reverted.

This may have been the cuase of your problems.

see this commit for details!