Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating for 4.0 Update #46

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

sysnet-ai
Copy link

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
Copy link

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

Copy link
Owner

@lpil lpil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@sysnet-ai
Copy link
Author

sysnet-ai commented Jan 13, 2023

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
Copy link
Owner

lpil commented Jan 14, 2023

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
Copy link

pnelson commented Nov 26, 2023

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
Copy link
Author

@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.


```sh
sonic-pi-tool sync 33926 1839294199
### Now sonic-pi-tool is sync'd with that server
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

fn write_config_toml(cfg: &config::SonicPiToolCfg) {
std::fs::create_dir_all(&config::SonicPiToolCfg::get_default_cfg_folder()).unwrap();
std::fs::write(&config::SonicPiToolCfg::get_default_cfg_file_path(),
toml::to_string(cfg).unwrap()).unwrap();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you run the formatter please? Thank you

@Sohalt Sohalt mentioned this pull request Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants