sonic-pi
sonic-pi copied to clipboard
CLI or API interface
Thank you for creating such a wonderful tool.
I am working on a project that generates a Sonic Pi track based on a dataset and I am looking for a way to call Sonic Pi to run/record the track.
I have read through the issue #19, but the tools mentioned there do not seem to work for me (even after a few tweaks to help them find the correct port).
Since I am writing a program, all I really need is some documentation on the Sonic Pi API over the UDP port. But having a CLI would work as well.
I may resort to OSC interface, but I'd prefer not to.
==
About my environment: I am running Ubuntu 22.04 and have built Sonic Pi from HEAD of the dev
branch.
I've been going down the rabbit hole of trying to get an external editor to work with Sonic Pi and it looks like none of the previously working methods are valid now. Looking at a half-dozen different repos, it looks like most of them still look at ${SONIC_PI_INSTALL_DIR}/app/server/ruby/bin/port-discovery.rb
which was removed by this commit in July 2021. Programs now need to look into ~/.sonic-pi/log/daemon.log
for lines similar to the following:
[2022-09-17 10:27:08] log: UTF-8, UTF-8, Ports: {:server_port=>35516, :gui_port=>35517, :scsynth_port=>35518, :scsynth_send_port=>35518, :osc_cues_port=>4560, :tau_port=>35519, :listen_to_tau_port=>35523}
Hi there,
@dylannorthrup is correct - all of the old methods were really hacks which were never guaranteed to continue working.
daemon.rb arrived in v4 and is the first step towards a properly supported CLI - and also for working with arbitrary external editors.
However, where @dylannorthrup isn't quite correct is that programs do not need to look into any log files for ports. This is definitely not supported and may well break in future releases. Instead, daemon.rb prints a list of ports to stdout - and this should be expected to continue to work in the future. daemon.rb also prints the security token to stdout which also needs to be used.
wrt APIs, the OSC interface is the API and will remain so for the future. The documentation should definitely be improved, but all of this stuff is still embryonic, in flux and has a high degree of churn. Build stuff which works with it by all means, but also be prepared to maintain it going forwards :-)
@samaaron , thanks for the clarification (and thanks for the software)!
However, where @dylannorthrup isn't quite correct is that programs do not need to look into any log files for ports. This is definitely not supported and may well break in future releases. Instead, daemon.rb prints a list of ports to stdout - and this should be expected to continue to work in the future. daemon.rb also prints the security token to stdout which also needs to be used.
I have a practical question regarding the future plans. Since the information is printed to STDOUT, is there no expectation to be able to programmatically determine the OSC port and token? My primary use case is to be able to use a third-party editor for my code. Having to update the token (and possibly the OSC port) in the editor settings every time would get very tedious. Having a standard/supported location to look at or a standard port on localhost
to query for that information would be very convenient. The current implementation make the log files a good place to find that information right now, but it would be nice if there were a supported method to get that info without having to manually type the info in each time. I would only expect this method to work via localhost
to prevent remote code execution from other hosts, but having it for the next version of sonic-pi-cli
(as an example) would be very nice.
Thanks again and I look forward to your thoughts on this.
Thank you for the answers. At the moment I am writing a SuperCollider file, since with a minimal wrapper I can produce an audio file out of it with a shell call to sclang <filename.scd>
. But I find Sonic Pi to be way more expressive and powerful and would love to switch.
Would it be possible to write a shell script that starts the deamon.rb
, parses the output for the port and token, sends the OSC commands to the said port and then terminates the Sonic Pi?
From what I gather:
$ ./code/sonic-pi/app/server/ruby/bin/daemon.rb
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
36878 36873 36872 36874 4560 36875 36877 2046335021
You have to specify a module index or name
The first number in the output is the UDP port for the OSC API.
The last number is the security token.
I tried to send a /version
OSC command to that port with the token in the arguments, but that did not seem to work. Plus the daemon.rb
terminates after several minutes.
Perhaps you may have a few more pointers for me as to how to start the daemon, interpret its output and communicate with it?
@dylannorthrup - the aim for daemon.rb was to support the usecase where users wanted to work with their own GUI or CLI. This means that your GUI/CLI process should start daemon.rb and work with the ports it prints to STDOUT. This is somewhat documented at the top of daemon.rb: https://github.com/sonic-pi-net/sonic-pi/blob/dev/app/server/ruby/bin/daemon.rb#L36
@voronaam unfortunately I haven't put any effort into documenting the use of daemon.rb beyond the comments there. If you're looking for examples to follow, then the best options are the C++ API here: https://github.com/sonic-pi-net/sonic-pi/tree/dev/app/api (which is something you could use if you're building a GUI/CLI and can interface with C++ easily as both the Qt and experimental IMGUI GUIs do). You could also take a look at this neovim plugin which talks to daemon.rb and is written in lua: https://github.com/magicmonty/sonicpi.nvim