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 ));
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.
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.
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.
-> a ServerOptions
-> a ServerOptions
realtimepi : setting clientID to 0.
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.
-> 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!!!
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”.
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.
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?
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?
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.