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:
Ports: {:server_port=>31213, :gui_port=>31214, :scsynth_port=>31215, :scsynth_send_port=>31215, :osc_cues_port=>4560, :tau_port=>31216, :listen_to_tau_port=>31220}
Token: -1066900612
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.