I’ve been experimenting tonight with Troop and Extramuros and Sonic-Pi-Tool in an attempt to get networked coding working. I’ve been able to get Sonic-Pi to receive the OSC messages from all three tools, but I’ve been unable to get Sonic-Pi to produce sound. I see the messages come into the Cues window but no sound occurs? Any ideas what I’m doing wrong?
Hi @carltesta - some more details about your setup would be very helpful. What version of Sonic Pi are you using? what operating system? any suspicious looking log messages in the log folder inside .sonic-pi in your home directory?, etc 
Thanks for offering to help. I’m using Sonic Pi 3.2.2 on MacOS Mojave 10.14.6. I’ve got Troop up and running and when I evaluate some code in Troop I get the following message in the Cues window in Sonic Pi but no sound:
/osc:127.0.0.1:56912/run-code ["0", "live_loop :one do\nplay 80\nsleep 1\nend"]
please post the code you use.
Thanks
by the way, what are these tools ? Software ?
They are both software tools for networked collaborative live coding.
1 Like
Are you expecting Sonic Pi to execute the code in the OSC message? It looks to me look you’re sending it to the wrong port.
Sonic Pi listens for OSC on two different ports, the OSC port that appears in the cue log - these don’t do anything on their own, you need code running in Sonic Pi to handle them - and the command port that is used internally by Sonic Pi for sending commands from the GUI to the server component.
I think you want to be sending to the command port - you can see what port that is by looking in .sonic-pi/logs/server-output.log once Sonic Pi is started.
1 Like
Hi @carltesta - by default Sonic Pi does not do anything within incoming OSC messages other than printing them to the screen and storing them in the event system.
Sonic Pi does not officially support receiving code via OSC - incoming OSC events are for data not code
It’s true that the GUI talks to the internal server in this way which can currently be hijacked by other GUI apps (such as VSCode or Emacs etc.) - but it’s an internal undocumented API and may change without notice or warning. If you do want to play with this API, you can see which port Sonic Pi is listening to the code API in the logs during boot up. This port is selected randomly during boot. It’s possible this will change and/or disappear in future versions as we tighten up security and restrict what code people can inject into the system.
I have already started to work on a restricted language subset which will be much safer to transmit over the wire rather than arbitrary Ruby code. The eventual plan is for all code to be remotely executed be encoded in this new language format. This will open up a whole set of new opportunities for multiple instances of Sonic Pi and external apps to start collaborating with greater expressivity 
@samaaron Thanks for the clarification. When using Troop with SuperCollider a Troop instance in SuperCollider is required via the TroopQuark which basically just registers an OSCFunc to evaluate the code included in the OSC message. Would it be possible to simply create some kind of responder on the Sonic-Pi end to evaluate these OSC messages which would be slightly more secure since you need to start something running?
It might be a compromise to make it easy to specify a specific API listening port on boot via a config file.
In general I want to hold back on remote code execution until I have this new network-ready language in place.
1 Like
I’d definitely be interested in working something out via a config file. I’m trying to work on some remote learning for students and I’m excited about the possibility of getting this working with Sonic Pi.