Connecting to scsynth running on a Raspberry Pi wirelessly from scide on a laptop

Questions
1

Hi,
I have successfully got SuperCollider to run on a Raspberry Pi 3 on boot with an scd file on the Raspberry Pi itself. I am currently trying to get SCIDE from my mac, on the same network, to control a server instance running on the pi. I haven’t found much documentation on this. Here is what I am doing now:

On the Raspberry Pi 3 (after starting Jack successfully) from a shell script:

/usr/local/bin/scsynth -u 57117 >synth_log &

On my mac, using the SuperCollider IDE:

(
    s = Server(\remoteServer2, NetAddr("192.168.1.67", 57117 ));
    s.serverRunning;
)

I have already ssh’d from that laptop to the “192.168.1.67” ip address successfully, so I know that the network is fine.
s.serverRunning returns false, which I assume means it didn’t connect.

Any ideas?

2

Hey Colin,

I think you want to take a look at Server.remote: http://doc.sccode.org/Classes/Server.html#*remote

Brian

3

Also make sure that port 57117 is open on the Rpi. The fact that you can ssh means that port 22 (default ssh port) is open, but probably SC port is not

4

Great, I am going to try this when I get home tonight and post the results. @Alberto_Gomez do you know the means of opening up local network ports on Raspbian? I am familiar with doing so on a web server via ufw, but I tried that command and found it was not installed on the Raspbian. So I just assumed all the ports would be open by default without ufw. I am fairly ignorant of how local networks work, though I’ve been able to ssh into the Raspbian. Sorry for asking a question out of the scope of SuperCollider, if there is a set of reading material for me to find to cure my ignorance, I will happily go searching for it.

5

I went looking for my own answer. It looks like I can see what ports are open with this command on Raspian:

sudo netstat -lptu

Will try this tonight and find out what ports are open and closed. It looks like there is no firewall on Raspbian by default. This command will hopefully clear up the question of whether or not I am having problems with ports.

6

Much thanks to everyone! I was able to get sound out of my Raspberry Pi with the following code on my SCIDE running on a seperate laptop on the same network:

o = ServerOptions.new;
o.maxLogins = 8;
s = Server.remote(\realtimepi, NetAddr("192.168.1.67", 57117), o);
s.serverRunning;
s.boot;
{ [SinOsc.ar(440, 0, 0.2), SinOsc.ar(442, 0, 0.2)] }.play(s);

Here is the output of Post window in SCIDE:

-> a ServerOptions
-> a ServerOptions
realtimepi : setting clientID to 0.
-> realtimepi
Requested notification messages from server 'realtimepi'
realtimepi - already registered with clientID 0.
realtimepi - handling login request though already registered - 
This seems to be a login after a loss of network contact - 
- reconnected with the same clientID as before, so probably all is well.

-> true
-> realtimepi
-> Synth('temp__1' : 1000)

In my shell script, I had to add jack_connect commands to hear the output. Because running sclang before made the jack connections for me, I forgot that step with scsynth. But as soon as I did that, I heard the sine waves over my Raspberry Pi!!!

Much much thanks!

7

I started a seperate question here related, but different from this one:

I am now trying to see if I can control the midi devices on the remote raspberry pi through the IDE on my mac. Feel free to comment there if anyone has insight.

8

@Colin_Brogan sorry didn’t see your message earlier but glad you found your way around trouble!

9

in case it could be helpful to others:
I couldn’t connect to my raspberry (Raspbian Jessie) until I started scsynth with a -B option:
scsynth -u 57110 -B 192.168.43.29

10

It’s important in this conversation to note:

Breaking change: scsynth had a security issue where it listens to 0.0.0.0 by default. For most users, this is undesirable behavior since it allows anyone on your local network to send messages to scsynth! This default has been changed to 127.0.0.1 (#4516). To change it back (e.g. for networked server/client setups), use -B 0.0.0.0 at the command line or server.options.bindAddress = “0.0.0.0”.

hjh

11

I carefully followed the tips in this thread, but my interpreter crashes whenever i try to execute s = Server.remote(\realtimepi, NetAddr("192.168.188.29", 57110)); and I get this message: Interpreter has crashed or stopped forcefully. [Exit code: 11]

I’m running Arch Linux, and AFAIK everything is setup just fine.

EDIT: Could this actually be a bug?

It’s not a problem for me to use VNC, but running scsynth on the pi from ssh and sending the commands remotely would be pretty nice system-resource wise.

12

@vvrng just a shot in the dark, but that sounds like it might be a bug we fixed in 3.11.1: https://github.com/supercollider/supercollider/pull/4927

are you running a VPN on either machine by chance? if stopping the VPN makes this go away then you won’t have to wait long; 3.11.1 will be released this week and packaged for Arch not long after. otherwise, would you mind getting a backtrace from the crash and creating a new issue for it here?

1 Like
13

Hi @VIRTUALDOG , first of all, thanks for the fast reply!

I am running WireGuard on my laptop, and I have some OpenVPN profiles configured but they weren’t running, so my guess is it was WireGuard’s fault. If I understood the git pull request correctly, it could be the problem, since WireGuard creates a virtual network interface.

How do I create a backtrace so we can verify this is the problem?

14

it’s almost certainly that bug, then. you can fix it now by turning off WireGuard when you run SC, or installing SC by building it yourself from the head of the 3.11 branch, or you can wait until 3.11.1 is packaged and available.

15

Allrighty then, I might just nuke WireGuard into orbit since I’m not using it anyway at the moment.

Thanks for the help!