Start Supercollider server in background

So recently I’ve been fiddling around with Supercollider a lot and asked myself, why not try to make vvvv communicate with it, as it is completely OSC based… but before I can call its methods I would need to start the server in the background. Is this possible in VL already? Or do I have to write this in c# like so:

My first guess would be that it might be possible via the executor with the appropriate arguments… I have found some ressources on this, but wanted to find out if this was the right approach before going further:

Would appreciate some tips!

is the “in background” really the first thing you need to solve? what happens if you just run SC via Executer as is or run it as you normally would (ie not launched from vvvv at all)?

No, not the first thing to solve at all, but still just something that I got curious about. Basically I am already controlling a patch from vvvv, so I thought defining SynthDefs and calling them or setting up the server from vvvv would be something to follow along afterwards.

1 Like

So I am coming back to this, making some progress on it. I have implemented a node in gamma that can open and close the server, listening to a UDP port which can be specified - so far so good and I am taking the next steps on calling the UGens.

What I am struggling with right now is the receiving OSC part, for getting callbacks of asychronous methods - I know it’s a bit early for this, but closing the server delivers a callback signal which would be nice to take into account. Also these callbacks will be needed very soon when making synth definitions.

The problem is that I can not activate a OSCServer on the same port which I am sending to, because that blocks the startup. But there is nothing else specified in the SC docs, so I guess it is by design that sending and receiving happens on the same port.

In a very old discussion on Github from 2013 I found this quote:
“This is a problem that clients need to solve by using bidirectional ports, and so far every program has managed to do this.” (Add optional port argument to /notify and async commands · Issue #801 · supercollider/supercollider · GitHub)

Any thoughts on this are very welcome!

as the linked article points out, sending/receiving on the same port is a rather unusual practice in OSC land. so the current OSC nodes don’t support this. our underlying UDP nodes though do support this. so it can certainly be built, but i don’t have a quick guide for you as to how to do this.

One of the guys in the thread mentions a bidirectional max object he has implemented. I think the underlying java code can be found here:

This class groups together a transmitter and receiver, allowing bidirectional
OSC communication from the perspective of a client. It simplifies the
need to use several objects by uniting their functionality.

Maybe it helps

Thanks for your replies! I also asked on the SC forum and in fact sending and receiving happens on the same port: Reply port of asychronous commands - scsynth

Will try to study the java implementation…

there is a HowTo UDP (Socket) in the helpbrowser, which covers the bidirectional socket part. so it is rather about studing the current OSC nodes and see how you can remodel them to work with that example.

1 Like

Thank you @joreg, it was actually pretty easy now using the help patch! Doing this, I am asking myself - wouldn’t it be good for cases like these to have a ReceiveOSC method within the OSCClient class?

good to hear it was easy. i’ll have to wrap my head around it re how to integrate this…

I was always asking myself why receiving OSC messages is directly liked to the OSCServer - for example there could be another instance of vvvv in the network providing the server and in that case you would only want Clients sending and receiving, right?

Btw, just to come back to the initial question and wrapping this up - starting the server is easy using the Executor node. Make sure to have Supercollider installed and the folder containing scsynth.exe added to the path variable.


vvvv gamma 5.1 now supports this, see: HowTo Receive OSC messages that were sent back to a client

1 Like