Can't get OSC /run-code to work

Hi there,

I’m struggling to get the VS Code Sonic Pi extension to work. It installs and registers all right. If I set the port numbers in the code to 4560, I get to cue messages in Sonic, like so

/osc:127.0.0.1:45824/run-code  [10, "play 60"]
/osc:127.0.0.1:45824/run-code  [10, "play 72"]

but apparently the code is not run. OSC is working – I can send and receive messages and use the cues for hooking up a sync. I can even use the /run-code cue to do just that, but it won’t execute the code it gets passed.

My Sonic Pi says it’s 3.2.0_dev, commit 315c316. I compiled it from sources on Ubuntu 18.04, but already some months ago.

Any suggestions, whether I should compile a newer version or there is just something wrong with my OSC messages, are highly appreciated.

Cheers,

Ben

can you show us the entire code ?

What do you mean ?

I believe that /run-code is supposed to run the string argument it gets passed as Sonic Pi code. If I remember correctly this is the command that the GUI uses in order to get the content of a buffer exectuted. The code I was referring to and which I think should be run by Sonic Pi in my example is play 60 and play 72. Does that answer your question?

Not sure if you are referring to the sonic-pi-cli gem here.
If you are, read this. If not ignore.

Sonic Pi 3.2 now uses a randomly generated port instead of the port 4557 previously used by sonic-pi-cli to communicate with the server. I pointed this out to the author of the package back in August 2019, and I also developed and submitted a PR for a new version, but it has not yet been adopted. I have been using this new version successfully since then, and it reads the correct allocated port from the sonic pi server output log which is updated everytime Sonic Pi is run.
I just reminded the author and he has now incorporated this, so if you reinstall sonic-pi-cli and install the latest version 0.1.3 then this should work with both Sonic Pi 3.2 and Sonic Pi 3.1 as it detects which is running.
You do NOT use the port 4560 for commands issued by sonic-pi-cli (sonic_pi binary)
Hope this gets you going.
use
gem install sonic-pi-cli -v 0.1.3

Hi, actually I haven’t used the sonic-pi-cli gem. I was under the impression that if I send an OSC message to Sonic Pi with the path /run-code, then the argument of that message is executed as if it were coming from a GUI buffer. I’ll give the gem a try.

Regarding the ports, my server-output.log says the following at the beginning:

Sonic Pi server booting...
Using primary protocol: udp
Detecting port numbers...
Listen port: 51235
  - OK
Scsynth port: 51237
  - OK
Scsynth send port: 51237
  - OK
OSC cues port: 4560
  - OK
Erlang port: 4561
  - OK
OSC MIDI out port: 51238
  - OK
OSC MIDI in port: 51239
  - OK
Websocket port: 4562
  - OK
Booting server...

I’ll try fiddling around with 4561.

Hi @bmx,

Port 4560 is for incoming OSC events. These just come in and get registered as OSC messages that don’t do anything unless you specifically write code that will get triggered when new events come in.

If port 4560 were to run arbitrary code coming in on an open port, that would be a huge security risk (it would essentially allow anyone who can send network messages to your machine to run arbitrary code on your machine).

Sonic Pi therefore runs a separate OSC server for the server API which includes /run-code but only listens on the local loopback network so remote machines cannot send to it. Also, for additional security this port is now randomised on boot. In the future things are likely to get even more constrained, but I will also be working on making it easy to boot a GUI-less server that allows you to set the port on boot, which should make working with external editors like VS Code much easier :slight_smile:

Hi Sam,

Many thanks, that was the info I needed. Actually, I was also wondering about the security implications that such a setup would have. I’ll leave the VS Code thing for later then.

Ben

1 Like

Now, here’s a little follow-up. My run-code question really was about finding an alternative to the normal GUI, because Alt-R wouldn’t work for me. So I thought, I’d check VS Code, but this approach doesn’t work anymore, for good reasons, see above.

After Sam’s reply I got back to the normal UI in order to find a way to get Alt-R working. I finally figured out that if the help panel is open, then in my German UI the language tab (“Sprache”) is assigned the keyboard shortcut Alt-R and happily consumes the event, so the buffer panel will never know I hit Alt-R. With the help panel closed, everything works fine. Just leaving this here, in case anybody ever faces the same little problem.

3 Likes