I’m trying to update my Sonic Pi setup. It’s been a while since the last time I dived into it and I really want to avoid using the default editor for reasons I’ve detailed elsewhere in another topic. For that reason, I managed to get sonic-pi-tool up and running. OSC messages sure are received, but I just read about the newly added OSC security (Can't get OSC /run-code to work - #6 by samaaron) while searching why Sonic Pi was ignoring the strings I was submitting. I’m using the port 4560 and I can see my messages received in the logs.
Is there a way to deactivate that feature somehow? I don’t really care about security or arbitrary injection in my Sonic Pi buffers. An alternative would be to know which port I should use at bootup. It would involve patching existing SP CLI tools but it’s already more doable.
Not quite sure what your asking here.
1 you can stop OSC messages being received by the local machine, or just by the local machine from external machines using "/os in the Preferences panel.
2 If OSC messages are accepted by the computer then all messages directed to port 4560 (the server listening port for cues) will be displayed, even though your machine may not programatically act on them. i.e. you need to have a line of the form n = sync "/osc:127.0.0.1:9000/mymessage"
where received data addressed to “/mymessage” and sent from ip address 127.0.0.1 on port 9000 will be stored in the list n. If you don’t care about the originating ip address and port you can use a wild card * to ignore them e n = sync "/osc*/mymessage"
This would respond to OSC messages from 192.168.1.2 sent from port 8000 for example. (provided you have the tick box for external OSC calls ticked)
OSC cues sent like these are documented and freely usable.
It is possible to produce a new version of the sonic-pi-cli command line interface which takes account of random allocation of the INTERNAL sonic pi port used for communications between the gui and the server, and indeed I have one working, which extracts data from the sonic pi logfiles to set up the correct environment which also includes a security token value. It is designed ONLY to run on the local machine and so maintains reasonable security, and the data it uses changes on every reboot of sonic pi. I haven’t published it as things have been changing in this area until fairly recently, and it would always come with a warning that it used unpublished data and code that might very well change in the future rendering it useless. That is why the current version of sonic-pi-cli is broken for sonic pi version 4 betas. Using the new version you can send code to be run in Sonic Pi from the local machine via the command line.
It is possible to produce a new version of the sonic-pi-cli command line interface which takes account of random allocation of the INTERNAL sonic pi port used for communications between the gui and the server, and indeed I have one working, which extracts data from the sonic pi logfiles to set up the correct environment which also includes a security token value
I am basically looking for this. Is it possible to get access to a version of the updated program? More specifically, I would also like to know if it is possible to remove that protection (maybe a toggle in the settings?) so that this port is perfectly deterministic every time Sonic Pi is booting.
On a more theoretical level, I wonder why such a protection is necessary. I understand that you can send and execute arbitrary Ruby code but I wonder what the probability that a malevolent user does it actually is. Is there another reason behind this?
That is why the current version of sonic-pi-cli is broken for sonic pi version 4 betas
Yes, and the same is true for sonic-pi-tool as well. It would also need a fix to include the same logic as sonic-pi-cli.
You’ld have to discuss this with Sam. There always has been a token but it hasn’t been utilised fully till now. I guess it may be to do with fact that we are moving towards much more collaboration between multiple instance of Sonic Pi, and it is useful to make sure that each only responds to what it should. (each instance would have its own token). As far as the ports go, in previous versions there was a mechanism to let you override/change ports, but this is no longer present. Again partly for the same reason, but also because there is considerable testing of ports during initialisation to make sure they are available and they are generated to ensure this is the case. I guess what you really want is an official cli input specification for Sonic Pi rather than the two main versions currently existing which have both had to undergo revisions as the internal working of Sonic Pi have evolved. I think the whole collaboration development will come much more to the fore in the next stage of development of Sonic Pi post version 4.0
As far as the cli program goes I basically just use a hack to read the Server Port and the Token values from the spider.log eg my current instance gives:
The values returned, particularly the Token will change each time SP is rebooted. They are then used in a standard OSC call to localhost on port <server_port> to send
“/run_code”,,
The code is essentially the same as the previous versions except to make sure that the correct values are obtained and used. The server port for example is in a different log file and the previous Token had to exist but could have any value. Obtaining the values is a hack, and not very nice.
btw I am calling the version I use sonic-pi-cli4 and its executable is sonic_pi4 rather than the previous sonic_pi. It might be possible to amalgamate with the previous versions, but the code would be messy, and I think the response time might suffer.
The server port is available directly from Sonic Pi using the undocumented puts @ports
which returns a list of the ports used, but I don’t think there is access to the Token directly.
You can test things by running SP, reading the two values from the spider log and then sending an OSC call appropriately. You can even send it from SP to itself! osc_send "localhost",31213,"/run-code", -1066900612,"play 72"
using the current values from my spider.log above, which won’t work on your machine.
Note there is a small delay on the first call for sonic_pi4 as it has to retrieve the data from the log file. I think further work could be done to optimise my rather crude code (which I haven’t published here) to do this. However you have sufficient info on what is needed to develop your own.
A more formal entry point for starting Sonic Pi - the new Daemon ruby script: sonic-pi/daemon.rb at dev · sonic-pi-net/sonic-pi (github.com). When executed, this script will ensure that all the required processes for Sonic Pi are both started and terminated (the audio synth server - SuperCollider, the language server - Spider, the IO server - Tau). It will also print to stdout all the ports you need to use and a security token which needs to be sent when you make certain API calls. You then need to send a keep alive message to the Daemon server every 5s to indicate things are still running.
Further information about how to work with the new Daemon script is written in the comments at the start of the file.
There’s also a lot more polish to be done in this area to make it nice to work with, but I just wanted to point out that work is definitely happening towards making it possible to build your own GUI for Sonic Pi - or use an existing text editor as the primary Sonic Pi GUI.
Thanks! That’s enough information to understand how I can start working on this! I’ll take a look at the file and see if I can come up with a Python script of some sort. Thanks again for the V4.0. It’s getting better and better
Let me know how you get on and if you run into any issues. There’s very likely a lot of low hanging fruit to tackle here.
I ended up writing a script replicating what sonic-pi-cli is doing but more specifically aimed to be integrated to a vim-slime session (Sonic Pipe). Following @robin.newman advice, I am just reading the token that ends up being written in one of the log files after boot. I implemented a basic /run-code and /stop-all-jobs function as well as something to store logs from improvised sessions, etc… The script can be twisted to function the same way as sonic-pi-cli. That’s something I might end up doing if it starts to diverge too far from the basic utility kind of tool in an interesting way. It’s enough to make music for now but it is very clunky and unpolished .
I haven’t started working on packaging it correctly to be distributed as a CLI tool. If someone wants to help on this matter, feel free to do a pull request. I wrote the script this afternoon so it’s a bit fresh!
Hi @Bubo its definitely not safe to rely on the log files to read the port numbers. This is likely to change without warning. Instead I would work with the daemon.rb script directly.
Hi! I have another version of the script that is taking its values from daemon.rb but it will take a bit more time to get it to run. The tricky part is the lack of information when running daemon.rb. What would be the easiest way to get live logs to check if Sonic Pi boots correctly? I’ll give it a try today.
.