Updating for 4.0 Update

[sysnet-ai]

Updated to SonicPi 4.3 and it broke all my vim integrations - So I figured I could wire it up.
I tested with vim-sonic-pi and everything is working but the :ShowLogs command. But running :!sonic-pi-tool logs works correctly - so it seems to be somewhere in the VimScript which I can't really get too deep into.
But outside of that, tests are passing and all commands are working as previous versions.

Changes Required:

• SonicPi changed the main entry point from server.rb to daemon.rb
• SonicPi went from fixed ports to a dynamic port allocation. Get the ports from the daemon's output and write it in a file.
• When starting from the daemon - It adds a kill switch to bring down all the processes that it started, which makes the teardown real easy - but it requires a repeating keep alive message.

Some Crates Added:
Serde / Serde_derive / toml: To easily serialize and deserialize the configuration file. Picked toml because it's well supported in rust and the configuration files of sonic pi are already toml. I figured using the same sonic-pi path was a good idea cause it avoids more clutter on the user's ~/

duct: To easily run the daemon and get the ports from the output.

Thanks for the tool :)! - Hope this helps!

[lilyinstarlight]

Thank you so much for this work!

I'll see if I can't give this a try some time in the next week, and I'll also see what's up with the logs in vim-sonic-pi so I can fix that

[lpil]

Neat! Could you document how to use the tool now and the version requirements? Thanks

[sysnet-ai]

Hi @lpil - Thank you.

Version Requirements:

• Rust Compiler: >1.56
• SonicPi: >4.0 (I've been testing with 4.3, but the changes to daemon.rb seem to come from 4.0 tag)

Regarding Documentation:

• Not sure what you mean here. I think all the commands should work as before these changes, as it only changed how to find the correct port for Sonic Pi. I tested most of my previous flows and only the logs following was failing on the vim plugin.

The only case that I guess would not be supported any more would be:

Before

• Start SonicPi application (Listens on pre-stablished port)
• Run sonic-pi-tool eval play :e5 (It will correctly pick up the pre-established port)
• Ping!

Now

• Start Sonic Pi application (Listens on a dynamic port)
• Run sonic-pi-tool eval play :e5 (It will not pick the right port)
• Silence :(

But is that a common use case where people starting the sonic pi application vs doing sonic-pi-start server?

[lpil]

Fab, thanks. Could we get these new requirements documented in the README?

It would be fab to have it work with the application if possible, this is how I would typically run it as I like to be able to read the documentation. I'm not sure if that is possible though.

[pnelson]

Thanks for your work - this is the closest I've been to a comfortable SuperCollider experience.

I'm still having a few issues around the paths for start-server. It won't run on NixOS because of the bin paths.

$  which sonic-pi
/etc/profiles/per-user/main/bin/sonic-pi
$  find /nix/store -type f -name daemon.rb
/nix/store/53ra8y5nw6zkipm5cglr3343q1x1zygi-sonic-pi-4.4.0/app/server/ruby/bin/daemon.rb

I managed to get the server to start by adding the following to the paths in start_server just to test it out:

String::from("/nix/store/53ra8y5nw6zkipm5cglr3343q1x1zygi-sonic-pi-4.4.0/app/server/ruby/bin"),

It "worked" in that it started the server but playback sounded like garbage, presumably because it is missing some paths that would be configured when run through the /etc/profiles/per-user/main/bin/sonic-pi wrapper - but there's no daemon.rb in that bin directory so that directory itself didn't work at all.

I started the Sonic Pi GUI and manually configured ~/.sonic-pi/tool/config.toml from the values in the logs and evaluation worked beautifully but I can't check the logs because the GUI is running:

$  sonic-pi-tool logs
Os { code: 98, kind: AddrInUse, message: "Address already in use" }
error: Unable to listen for Sonic Pi server logs, address already in use.

This may because the Sonic Pi GUI is running and already listening on the desired port.
If the GUI is running this command cannot function, try running just the Sonic Pi server.

Any idea what's going on? Is there a more portable way to detect the paths for start-server?

[sysnet-ai]

@lpil - A bit of a necro, but I have been into other things and this wasn't really a priority. I added a sync command that allows you to sync with the GUI with a bit of unix command-ering to get the port and token. Couldn't think of a different way of doing it - but added some documentation for it.

@pnelson - Thanks for reminding me about this branch :P - I don't know if there's a more portable way of detecting where the binary lives without some potentially involved work, not familiar with how NixOS is installing SonicPi.
I added a bit of code to make starting the server with the GUI a bit simpler so you don't have to do the writing of the toml yourself.
I think reading the logs while the app is open is probably not gonna work thou - If I understand correctly, SonicPi sends the log to the port of a 'logs listener', if the App is open that port is gonna be taken by the UI that shows the logs, and I don't think you can make it so it sends to 2 different ports.
I might be wrong, but this is roughly as far as my understanding goes.

[lpil]

The user should be able to read this document and then know all need to know to be able to use the tool, so they'll need to know what numbers to use here.

[lpil]

Could you run the formatter please? Thank you