OSC does not work even with the preamble

[Daniel Otterbach]

Hi,
I like the tool very much. My next step was to use the OSC function of SP. I am running Sonic Pi without GUI. When I tried running the following code nothing happened:

live_loop :listen do
  use_real_time
  n = sync "/osc*/play_this"
  synth :saw, note: n
end

Even with the --premble paramter, this was the logs output:

=> Starting run 3

Runtime Error: [eval] - Errno::EADDRINUSE
Thread death!
 Address already in use - bind(2) for "127.0.0.1" port 4557
/opt/sonic-pi/app/server/ruby/lib/sonicpi/osc/udp_server.rb:31:in `bind'
/opt/sonic-pi/app/server/ruby/lib/sonicpi/osc/udp_server.rb:31:in `initialize'
eval:in `new'
eval:in `block (2 levels) in __spider_eval'
/opt/sonic-pi/app/server/ruby/lib/sonicpi/runtime.rb:781:in `eval'
/opt/sonic-pi/app/server/ruby/lib/sonicpi/runtime.rb:781:in `block (2 levels) in __spider_eval'
/opt/sonic-pi/app/server/ruby/lib/sonicpi/runtime.rb:1042:in `block (2 levels) in __in_thread'

=> Completed run 3

=> All runs completed

=> Pausing SuperCollider Audio Server

Can you help me please? The cue server does not seem to work.

[Emlyn Corrin]

Hi, have you checked that the same code works when run in the GUI?

[Daniel Otterbach]

Yes, the code works perfectly with the GUI.

[Lily Foster]

It looks like based on the settings, the GUI turns on the cue server itself by sending the /cue-port-start OSC command (it also then sends /cue-port-external or /cue-port-internal depending on the "Allow OSC from other computers" setting).

If I add in subcommands to sonic-pi-tool that send these OSC commands, the cue server functions correctly when the server is started outside of the GUI.

Relevant cue server start code: https://github.com/sonic-pi-net/sonic-pi/blob/v3.2.2/app/gui/qt/mainwindow.cpp#L2878-L2911
Which is called on server startup by the GUI: https://github.com/sonic-pi-net/sonic-pi/blob/v3.2.2/app/gui/qt/mainwindow.cpp#L244

If @emlyn would like, I can submit a PR for adding cue server management support. If so I would like input on whether this should be managed as flags on the start-server subcommand or whether there should be different subcommands for managing the cue server (including whether that means one subcommand does start/stop/external/internal, four subcommands, two subcommands for each managing cue server status and external port status, etc.). I can also add both flags on start-server and separate subcommands if that is desired.

[Emlyn Corrin]

Thanks for working that out @lilyinstarlight - if you want to submit a PR that would be great!
I think it would probably work best as a flag on the start-server command, as it wouldn't normally need to be changed during a run.
Something like --cue-server that can be off, internal or external, with a default of internal? That seems like the most useful to me, but I'm open to other ideas.

[Lily Foster]

That sounds like the reasonable way to do it and I'll see if I can submit a PR this weekend sometime. It won't be a particularly involved change since it's just sending another two OSC commands after server startup probably between these two lines but I'll work on it and do some testing.

Thanks!

[Emlyn Corrin]

Hi @DanielOtter, I think this should be fixed now thanks to @lilyinstarlight's PR. If you still have trouble with it, feel free to reopen this issue, or create a new one.

[Daniel Otterbach]

Hi @emlyn and @lilyinstarlight ,

I've read your comments and thanks for solving this problem. I will definately use this feature in the near future. Thanks again.