The SC client (which handles OSCresponder, OSCresponderNode etc.) always receives OSC on port 57120. That's hardcoded. If you have two instances of sclang running, one will use 57120 and I think the next will roll up to 57121.

The server's default port is 57110. You can change the port before booting the server using s.addr.port = (port number). The port number here gets included in the scsynth command, and that is the port the server tries to open.

scsynth -u 57110 -b 1026 -R 0

As far as I know, there isn't a way to change the server's listening port without stopping and restarting the server.

Dunno if this has confused more than clarified. Feel free to ask other questions.

There's nothing inherent in the language to prevent setting the control in the synth, so I have to suppose it's one of a couple of things.

Have you checked to make sure the incoming OSC message is properly received? You can check a couple of ways: by adding "msg.postln;" in your OSCresponderNode, or doing this to see all incoming OSC. (It's a good idea to filter out /status.reply messages from the server, since there will be a lot of them.)

The reason why NetAddr.localAddr does not work in an OSC responder is that this is the address and port that supercollider is listening to. The OSC responder (if the port is given) needs to have the port FROM which the messages are coming. If Max is sending FROM port 7771, then the address given to the OSC responders should be NetAddr("localhost", 7771).

Then Max needs to send TO port 57120. But understand -- the fact that Max is sending TO this port does not mean that the OSC responder should have this port in its address.

I know this is confusing... I'm not sure how else I can explain it to make it clear.

Think of it this way -- the address in the OSC responder is a filter to prevent that responder from taking action based on the wrong source. Supercollider's listening port (57120) is useless as a filter because every message coming into the supercollider language is received at this port! It is meaningful only if it refers to the port that the other application is using to send messages FROM.

CombC -- right now you're sending instantaneous changes in the delay time, which will give you nasty clicks. Try wrapping the delay time in a Lag, to smooth the transition.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.