So I’m trying to run Sonic Pi with a RPi without any gui, as I’ll be using it to make a sort of live synth/seqencer. I’m controlling everything using Python and using psonic to interface Python with Sonic Pi.
When I open Sonic Pi non-headless (with the gui and everything) it all works fine.
But as soon as I start only the Sonic pi Server (i’ve tried both directly starting it with ruby and using ‘sonic-pi-tool’) the server only responds to run commands, and does not receive any OSC cues. Why is this? How can I fix this?
I’ve also tried sending direct OSC cues without using psonic, and to no avail.
I ran into that issue when making a Python version of sonic-pi-tool, and found this issue-comment. In short, you can get it working by adding the following to the start of any code you evaluate:
I’d love to use it, but I’m just wondering how I’d run a control command with an OSC cue with the resource without having to send my own OSC cue (the source of my problem)?
I’m not sure I’ve understood exactly what’s not working, but I think once the above snippet has been run on the Sonic Pi server (using sonic-pi-tool eval "code..."), the OSC server should be running and from that point it should respond to OSC cues.
When trying to start the server using your tool, I get this error.
Regardless, I’ve been trying to use the sonic-pi-tool written in rust that your tool is likely based off of. The server starts fine using the rust-based implementation.
But even with the code header you suggested, my error persists. Allow me to explain my problem in greater detail.
I’m running this Python Script. Everything works exactly as intended (albeit a little slow) when using Sonic Pi with its GUI.
When I start the Sonic Pi server using any method that isn’t opening its’ GUI, my program does not work as intended. The run() part of the code does, but this part does not: sender.send_message('/trigger/prophet', [(72-n), 1]);
I assume this is because the server is not receiving OSC cues when it is not running with the gui. The problem persists despite that fact that I’ve added @osc_server ||= SonicPi::OSC::UDPServer.new(4559, use_decoder_cache: true)
to the beginning of the one piece of code that is ran on the server.
Is there any other way you know of to fix this? Am I implementing the header wrong?
I think the error in my script is probably to do with differences between different Python versions, as I haven’t tested it very thoroughly. What version of python are you using? You could try using a different version if you have one installed (e.g. python3 sonic-pi-tool.py eval ...).
However, I’m not very hopeful that will help, as it looks like what you’ve done to add the OSC setup code at the start should be doing the same thing anyway.
If I get a bit of spare time I’ll see if I can reproduce your problem and work out what’s going on.
Thanks in advance! I’ve been searching for 20+ hours at this point trying to find a solution, anything you can find that I can’t would be immensely helpful!
I tried out your code, and I see the same thing. The fix above used to work for what I’m pretty sure was the same problem, but maybe that was with an older version of Sonic Pi.
I’m not really sure what else to try, but I found a Sonic Pi commit that looks like it might fix this in the next version, so hopefully that comes out soon and you can try with that. Or you could try compiling it yourself, although it can be a bit fiddly - I’ve done it in the past but can’t get it working at the moment.
I might try and compile the development version if it really comes down to it. I’m not too familiar with ruby though, so it might take me a while. Should I submit an issue report on github?
If you do try to build it yourself, I’ve found the build-osx-app script in the app/gui/qt folder to be a good starting point (if you are on OSX, there are others for other platforms). But it generally doesn’t just work first time, so I usually copy the commands out and execute them one by one manually, trying to fix things as I go along.
You could file an issue if you want. I suspect the response will be that this is not a supported use of Sonic Pi, but you might get some hints on how to work around it (or whether it’s likely to be fixed in the dev version and therefore worth trying to build it).
I take a slightly differnt approach to running Sonic Pi headless, which is to run it with the gui in a virtual X windows using the tehcnique shown here
I have used this with quite a few projects and it seems to work well.
For the record, headless support with Sonic Pi has never been officially supported. I hope to change this in the future but for now, the GUI is required.
Of course it should be possible to get things working with some coding and experimentation but it’s not something I have the energy to support at this stage.
I can say that my new studio is making the idea of headless Sonic Pi instances useful for me personally so I think there’s a good chance this situation will change in the short to medium term
