Perhaps the NetAddr help should be updated as this does seem to be a
perennial confusion. Or a new overview file?
S.
On 6 Mar 2008, at 00:41, nescivi wrote:
> On Wednesday 05 March 2008 19:34:08 nonprivate wrote:
>> hi marije (sorry the j got lost last time) thanks again,
>> so the port in the OSCresponder argument is to specify the port
>> that the
>> message is being sent from (ie port XXXX in your example) is that
>> correct?
>
> yes.
>
>
>>
>> (i don't mean to drive you crazy, replying is optional...)
>>
>> nescivi wrote:
>>> Hiho,
>>>
>>> On Wednesday 05 March 2008 12:23:57 nonprivate wrote:
>>>> hi marie, thanks for the reply!
>>>> i'm obviously getting confused, because i thought sc could only
>>>> listen
>>>> to things coming in from 57120? which is what i thought you and
>>>> till
>>>> said before.
>>>> and if i use the monome or akaRemote, and set them to send to a
>>>> port
>>>> number that isn't 57120, sc doesn't get anything. max/msp picks up
>>>> everything though.
>>>
>>> it seems to be a difficult concept.
>>>
>>> app A sends a message out *from* port XXXX
>>> *to* port 57120, on which SuperCollider listens.
>>>
>>> so
>>> appA -> port XXXX -> port 57120 -> SClang
>>>
>>> upon startup SC picks a port to listen to, normally 57120, if
>>> that isn't
>>> available, it takes the next one, and so on. The current can
>>> always be
>>> checked by NetAddr.langPort
>>>
>>> To send a UDP message, an application needs to open up a port,
>>> kick the
>>> message out of that port, in the direction of the port the
>>> message needs
>>> to go to, on that port another application may or may not be
>>> listening.
>>>
>>> sincerely,
>>> Marije
>>>
>>>> nescivi wrote:
>>>>> Hiho,
>>>>>
>>>>> On Wednesday 05 March 2008 10:51:40 nonprivate wrote:
>>>>>> thanks till, it does help to know that!
>>>>>> in that case, it doesn't really make sense to specify a port for
>>>>>> OSCresponder to listen to, does it (?)
>>>>>
>>>>> yes, it does.
>>>>> It determines to listen for messages coming *from* a specific
>>>>> port.
>>>
>>> _______________________________________________
>>> sc-users mailing list
>>> sc-users@... >>> http://lists.create.ucsb.edu/mailman/listinfo/sc-users >
>
> _______________________________________________
> sc-users mailing list
> sc-users@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-users
for those who don't know me, i am one of those Pd freaks...
William Brent wrote:
> > why don't you just _use_ nil as the NetAddr in the responder?
>
> Yep, it makes sense. That's what I have done in the past. On top of
> the security ambiguities you mentioned (which make it not so worthwhile
> to use a specific port with Pd), it would also be irritating to have to
> check which port Pd happens to be using each time I run it, because it's
> not consistent from one instance to the next (though, once launched, it
> sticks with the same port).
i just wanted to say, that this is _perfectly normal_ behaviour of any
client application in the wide internet.
each time i access a website with my browser, the browser will choose an
_arbitrary_ port to send from and will send to port:80 (http).
no browser i heard of will ever send _from_ port 80.
i don't think anyone should go and try to re-define how internet
connection ought to work.
i only know of 2 applications that care for the sender-port: SC3 and
firewalls.
i am not sure whether it is so good to build firewall functionality into
an audio application, but i don't want to start a flame war.
> Everything is clear now. And I think it raises a good issue for Pd and
> Max users. From what I'm understanding, specifying everything in detail
> like this is maximally secure and reliable.
afair, it is an added security to _not_ be able to pre-determine the
sending port (man-in-the-middle attack); but i might be mistaken here (i
couldn't find anything now)
> Maybe sendOSC and udpsend
> should be updated...
the only thing i could imagine that might be "fixed" is to set the
source-port to "0" indicating that this is a uni-directional connection.
even if it does not, my understanding of RFC768 does not require that a
sender has to _listen_ at the source-port for feedback ("Source Port is
an optional field, when meaningful, it indicates the port of the sending
process, and may be assumed to be the port to which a reply should
be addressed in the absence of any other information.")
finally, OSC does not say anything about the underlying protocol.
especially it does not mention bi-directional communication.
i guess one should not rely on a "custom to send reply messages" if one
wants to communicate with other applications.
sorry for the noise
fgmasdr
IOhannes
PS: in Pd, beware of [sendOSC], it is really broken.
Your message isn't noise, I believe you're right. (By the way I almost
didn't see your P.S. ;)
Most client/server-based TCP/UDP stuff uses a fixed port on the server
and an ephemeral port on the client, and that's as designed.
I suspect this implies that SC's NetAddr should really allow for a
wildcard source port, as someone else mentioned; but I haven't looked
much at NetAddr and friends, so I'm not sure exactly what changes that
would require.
> hi all, sorry to chime in.
>
> for those who don't know me, i am one of those Pd freaks...
>
>
> William Brent wrote:
> > > why don't you just _use_ nil as the NetAddr in the responder?
> >
> > Yep, it makes sense. That's what I have done in the past. On top of
> > the security ambiguities you mentioned (which make it not so worthwhile
> > to use a specific port with Pd), it would also be irritating to have to
> > check which port Pd happens to be using each time I run it, because it's
> > not consistent from one instance to the next (though, once launched, it
> > sticks with the same port).
>
>
> i just wanted to say, that this is _perfectly normal_ behaviour of any
> client application in the wide internet.
>
> each time i access a website with my browser, the browser will choose an
> _arbitrary_ port to send from and will send to port:80 (http).
> no browser i heard of will ever send _from_ port 80.
>
> i don't think anyone should go and try to re-define how internet
> connection ought to work.
>
> i only know of 2 applications that care for the sender-port: SC3 and
> firewalls.
>
> i am not sure whether it is so good to build firewall functionality into
> an audio application, but i don't want to start a flame war.
>
>
>
> > Everything is clear now. And I think it raises a good issue for Pd and
> > Max users. From what I'm understanding, specifying everything in detail
> > like this is maximally secure and reliable.
>
>
> afair, it is an added security to _not_ be able to pre-determine the
> sending port (man-in-the-middle attack); but i might be mistaken here (i
> couldn't find anything now)
>
>
>
> > Maybe sendOSC and udpsend
> > should be updated...
>
>
> the only thing i could imagine that might be "fixed" is to set the
> source-port to "0" indicating that this is a uni-directional connection.
> even if it does not, my understanding of RFC768 does not require that a
> sender has to _listen_ at the source-port for feedback ("Source Port is
> an optional field, when meaningful, it indicates the port of the sending
> process, and may be assumed to be the port to which a reply should
> be addressed in the absence of any other information.")
>
> finally, OSC does not say anything about the underlying protocol.
> especially it does not mention bi-directional communication.
> i guess one should not rely on a "custom to send reply messages" if one
> wants to communicate with other applications.
>
>
> sorry for the noise
>
> fgmasdr
>
> IOhannes
>
>
> PS: in Pd, beware of [sendOSC], it is really broken.
>
>
> _______________________________________________
> sc-users mailing list
> sc-users@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-users >
>
>
> On 6 Mar 2008, at 13:57, Dan Stowell wrote:
>
>
> I suspect this implies that SC's NetAddr should really allow for a
>
> wildcard source port, as someone else mentioned; but I haven't looked
>
> much at NetAddr and friends, so I'm not sure exactly what changes that
>
> would require.
>
> Is there a need for a change?
> The solution has always been to use nil instead of a specific NetAddr and
> it then accepts all sending ports.
The difference is that with "nil" you also accept all IPs. How much of
a difference this makes in practice, I'm not sure, but it would
presumably prevent you from (e.g.) only listening to 127.0.0.1
(localhost)? Which is a shame securitywise.
On 06.03.2008, at 13:43, IOhannes m zmoelnig wrote:
> for those who don't know me, i am one of those Pd freaks...
welcome to the bright side of life ;)
> William Brent wrote:
>>> why don't you just _use_ nil as the NetAddr in the responder?
>>
>> Yep, it makes sense. That's what I have done in the past. On top of
>> the security ambiguities you mentioned (which make it not so
>> worthwhile
>> to use a specific port with Pd), it would also be irritating to
>> have to
>> check which port Pd happens to be using each time I run it,
>> because it's
>> not consistent from one instance to the next (though, once
>> launched, it
>> sticks with the same port).
>
> i just wanted to say, that this is _perfectly normal_ behaviour of any
> client application in the wide internet.
>
> each time i access a website with my browser, the browser will
> choose an
> _arbitrary_ port to send from and will send to port:80 (http).
> no browser i heard of will ever send _from_ port 80.
and it doesn't matter because TCP is connection-oriented; the server
doesn't need to know the sender's address to deliver information back
to the client.
> i don't think anyone should go and try to re-define how internet
> connection ought to work.
>
> i only know of 2 applications that care for the sender-port: SC3 and
> firewalls.
>
> i am not sure whether it is so good to build firewall functionality
> into
> an audio application, but i don't want to start a flame war.
the sender address discrimination scheme in OSCresponder has nothing
to do with security concerns. just specify a nil address when
registering and you will get messages from any client delivered to
the corresponding responder. since UDP is connectionless, though,
there are scenarios that require message dispatch based on the
sender's identity.
>> Maybe sendOSC and udpsend
>> should be updated...
>
> the only thing i could imagine that might be "fixed" is to set the
> source-port to "0" indicating that this is a uni-directional
> connection.
> even if it does not, my understanding of RFC768 does not require
> that a
> sender has to _listen_ at the source-port for feedback ("Source
> Port is
> an optional field, when meaningful, it indicates the port of the
> sending
> process, and may be assumed to be the port to which a reply
> should
> be addressed in the absence of any other information.")
as soon as bidirectional communication is involved with UDP (scsynth
is just one example), it makes a lot of sense to use the same port
for receiving and sending, because then one less bit of information
needs to be exchanged (the sender's address), as stated in the RFC.
it would be great if the pd implementation could be updated to
optionally allow using the same socket for sending and receiving.
> finally, OSC does not say anything about the underlying protocol.
> especially it does not mention bi-directional communication.
> i guess one should not rely on a "custom to send reply messages" if
> one
> wants to communicate with other applications.
OSC only defines a message exchange format, but a particular
application level protocol built on top of OSC might require
bidirectional communication to communicate state changes.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
On Thursday 06 March 2008 03:50:47 Scott Wilson wrote:
> Perhaps the NetAddr help should be updated as this does seem to be a
> perennial confusion. Or a new overview file?
How about the attached one?
sincerely,
Marije
OSC_communication
OSC communication between programs is often done to send
messages from one application to another, possibly with the applications
running on different computers. In SuperCollider this communication is done
by creating a NetAddr of the target application and creating an OSCresponder
to listen to another application. The underlying protocol of OSC is either
UDP or TCP.
To establish communication to another application, you need to know on which port that application is listening. For example if an application is listening on port 7771, we can create a NetAddr and send it a message:
b =
NetAddr.new("127.0.0.1", 7771);
// create the NetAddr
b.sendMsg("/hello", "there");//
send the application the message "hello" with the parameter "there"
To listen to another application, that application needs to send SuperCollider a message to the port SuperCollider is listening on, normally this is 57120, but it can change. The current port can be retrieved with
NetAddr.langPort;
// retrieve the current port SC is listening to
Or you can retrieve both the IP and the port with:
NetAddr.localAddr;
// retrieve the current IP and port
To listen to incoming message an OSCresponder needs to be created in SuperCollider. If the sending application has a fixed port it sends message from, you can set the OSCresponder to listen only to messages coming from that IP and port:
n =
NetAddr.new("127.0.0.1", 7771);
// create the NetAddr
o =
OSCresponder.new(n, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add;
// create the OSCresponder
o.remove;
// remove the OSCresponder when you are done.
Some applications (notably Pd and Max) do not send messages from a fixed port, but instead use a different port each time they send out a message. In that case the OSCresponder needs to be set up, so that it listens to messages coming from anywhere:
o =
OSCresponder.new(nil, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add;
// create the OSCresponder
o.remove;
// remove the OSCresponder when you are done.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Marije,
Very useful. Still not able to work on Helper for Linuxers, but at least I can use it.
In attachment a "formatting template - compliant" version (Help.makeHelp("OSC_communication")).
Best
-a-
OSC_communication
OSC communication between programs is often done to send messages from one application to another, possibly with the applications running on different computers. In SuperCollider this communication is done by creating a NetAddr of the target application and creating an OSCresponder to listen to another application. The underlying protocol of OSC is either UDP or TCP.
Setting up an OSC connection
To establish communication to another application, you need to know on which port that application is listening. For example if an application is listening on port 7771, we can create a NetAddr and send it a message:
b = NetAddr.new("127.0.0.1", 7771); // create the NetAddr
b.sendMsg("/hello", "there");// send the application the message "hello" with the parameter "there"
To listen to another application, that application needs to send SuperCollider a message to the port SuperCollider is listening on, normally this is 57120, but it can change. The current port can be retrieved with
NetAddr.langPort; // retrieve the current port SC is listening to
b.cleanUp;
Or you can retrieve both the IP and the port with:
NetAddr.localAddr; // retrieve the current IP and port
To listen to incoming message an OSCresponder needs to be created in SuperCollider. If the sending application has a fixed port it sends message from, you can set the OSCresponder to listen only to messages coming from that IP and port:
n = NetAddr.new("127.0.0.1", 7771); // create the NetAddr
o = OSCresponder.new(n, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add; // create the OSCresponder
o.remove; // remove the OSCresponder when you are done.
Connecting to applications sending from a variable port
Some applications (notably Pd and Max) do not send messages from a fixed port, but instead use a different port each time they send out a message. In that case the OSCresponder needs to be set up, so that it listens to messages coming from anywhere:
o = OSCresponder.new(nil, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add; // create the OSCresponder
o.remove; // remove the OSCresponder when you are done.
On 7 Mar 2008, at 00:44, nescivi wrote:
On Thursday 06 March 2008 03:50:47 Scott Wilson wrote:
Perhaps the NetAddr help should be updated as this does seem to be a
On Thursday 06 March 2008 19:02:48 Andrea Valle wrote:
> Hi Marije,
>
> Very useful. Still not able to work on Helper for Linuxers, but at
> least I can use it.
> In attachment a "formatting template - compliant" version
> (Help.makeHelp("OSC_communication")).
I did start out from a file created by Helper, but as soon as I got to editing
it in Amaya (not really succesfull), and then Quanta (at least that didn't do
weird stuff), some of it gets lost..
I notice one "b.cleanup" line in your version that is out of place.
Sincerely,
Marije
>
> Best
>
> -a-
> 
>
> On 7 Mar 2008, at 00:44, nescivi wrote:
> > On Thursday 06 March 2008 03:50:47 Scott Wilson wrote:
> >> Perhaps the NetAddr help should be updated as this does seem to be a
> >> perennial confusion. Or a new overview file?
> >
> > How about the attached one?
> >
> > sincerely,
> > Marije<OSC_communication.html>________________________________________
> > _______
> > sc-users mailing list
> > sc-users@... > > http://lists.create.ucsb.edu/mailman/listinfo/sc-users >
> --------------------------------------------------
> Andrea Valle
> --------------------------------------------------
> CIRMA - DAMS
> Università degli Studi di Torino
> --> http://www.cirma.unito.it/andrea/ > --> http://www.myspace.com/andreavalle > --> andrea.valle@... > --------------------------------------------------
>
>
> "
> Think of it as seasoning
> . noise [salt] is boring
> . F(blah) [food without salt] can be boring
> . F(noise, blah) can be really tasty
> "
> (Ken Perlin on noise)
Great Marije, this file will really be helpful for people.
One note: >Some applications (notably Pd and Max) do not send messages from a
fixed port, but >instead use a different port each time they send out a
message.
Not sure if I was clear when I reported back about this, but it seems like once Pd and Max are set up to start sending OSC, the same port is used for each message transmission. It's only upon disconnecting/reconnecting, or quitting the application and starting it up again that the port changes.
A tiny point, I know, but thought I'd throw it in there while the ink was still wet...
On Thu, Mar 6, 2008 at 4:06 PM, nescivi <nescivi@...> wrote:
Hiho,
On Thursday 06 March 2008 19:02:48 Andrea Valle wrote:
> Hi Marije,
>
> Very useful. Still not able to work on Helper for Linuxers, but at
> least I can use it.
> In attachment a "formatting template - compliant" version
> (Help.makeHelp("OSC_communication")).
I did start out from a file created by Helper, but as soon as I got to editing
it in Amaya (not really succesfull), and then Quanta (at least that didn't do
weird stuff), some of it gets lost..
I notice one "b.cleanup" line in your version that is out of place.
Sincerely,
Marije
>
> Best
>
> -a-
> 
>
> On 7 Mar 2008, at 00:44, nescivi wrote:
> > On Thursday 06 March 2008 03:50:47 Scott Wilson wrote:
> >> Perhaps the NetAddr help should be updated as this does seem to be a
> >> perennial confusion. Or a new overview file?
> >
> > How about the attached one?
> >
> > sincerely,
> --------------------------------------------------
> Andrea Valle
> --------------------------------------------------
> CIRMA - DAMS
> Università degli Studi di Torino
> --> http://www.cirma.unito.it/andrea/
> --> http://www.myspace.com/andreavalle
> --> andrea.valle@...
> --------------------------------------------------
>
>
> "
> Think of it as seasoning
> . noise [salt] is boring
> . F(blah) [food without salt] can be boring
> . F(noise, blah) can be really tasty
> "
> (Ken Perlin on noise)
> hi IOhannes,
>
> On 06.03.2008, at 13:43, IOhannes m zmoelnig wrote:
>> for those who don't know me, i am one of those Pd freaks...
>
> welcome to the bright side of life ;)
i should say something really clever here, how light and bright and
night Pd really is. i leave this as an exercise to the reader.
>>
>> each time i access a website with my browser, the browser will
>> choose an
>> _arbitrary_ port to send from and will send to port:80 (http).
>> no browser i heard of will ever send _from_ port 80.
>
> and it doesn't matter because TCP is connection-oriented; the server
> doesn't need to know the sender's address to deliver information back
> to the client.
while you are right and my example was probably a not so strong one, i
still stand by what i say.
>
> the sender address discrimination scheme in OSCresponder has nothing
> to do with security concerns.
i used "security" mainly because it was already part of the discussion.
>
> as soon as bidirectional communication is involved with UDP (scsynth
> is just one example), it makes a lot of sense to use the same port
> for receiving and sending, because then one less bit of information
> needs to be exchanged (the sender's address), as stated in the RFC.
the RFC states that the sender port can be submitted in the
UDP-header, and that this port "may be assumed to be the port to which
a reply should be addressed".
i would say that this makes it clear that no assumption should be made
that the sender and receiver port ought to be the same.
and it makes perfect sense, e.g. if you have two clients on the same
machine communicating with one server, you probably want to be able to
discriminate them (without having to open 2 ports on the server!)
> it would be great if the pd implementation could be updated to
> optionally allow using the same socket for sending and receiving.
all udp implementations in Pd currently are unidirectional.
however, you can create a [udpsend] to port <xyz> and, in the same
patch, a [udpreceive] that listens at port <xyz>, which might help (or
not).
(it still would involve 2 independent sockets)
nevertheless, somebody could write a bi-directional udp object, which
should do no harm :-)
> OSC only defines a message exchange format, but a particular
> application level protocol built on top of OSC might require
> bidirectional communication to communicate state changes.
i totally agree.
i just commented on marije's "in OSC it is custom to send a reply"
which it is not (imho). remove the O and i will agree to "in SC it is
custom to send a reply".
if it is _required_ to follow this custom (instead of being optional)
in order to make a communication with a certain application work, than
the docs should clearly say so (which they might do anyhow;
unfortunately, i cannot check now)
mfga.sdr
IOhannes
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
On Saturday 08 March 2008 13:45:39 zmoelnig@... wrote:
> > as soon as bidirectional communication is involved with UDP (scsynth
> > is just one example), it makes a lot of sense to use the same port
> > for receiving and sending, because then one less bit of information
> > needs to be exchanged (the sender's address), as stated in the RFC.
>
> the RFC states that the sender port can be submitted in the
> UDP-header, and that this port "may be assumed to be the port to which
> a reply should be addressed".
>
> i would say that this makes it clear that no assumption should be made
> that the sender and receiver port ought to be the same.
> and it makes perfect sense, e.g. if you have two clients on the same
> machine communicating with one server, you probably want to be able to
> discriminate them (without having to open 2 ports on the server!)
I don't see your argument here.
We agree on this. The server listens on one port only. The clients send from
different ports, since they cannot use the same port.
> > it would be great if the pd implementation could be updated to
> > optionally allow using the same socket for sending and receiving.
>
> all udp implementations in Pd currently are unidirectional.
> however, you can create a [udpsend] to port <xyz> and, in the same
> patch, a [udpreceive] that listens at port <xyz>, which might help (or
> not).
> (it still would involve 2 independent sockets)
>
> nevertheless, somebody could write a bi-directional udp object, which
> should do no harm :-)
unidirectionality is not the problem.
It is more that in order to be sure that messages come from the right client,
important in open, i.e. running over an open network, configuration, that the
Pd send object needs to be able to specify a port from which it sends, in
addition to to which it sends.
OTOH, as I understood from Brent's explanation, once Pd has chosen a random
port, it sticks with that one for as long as it keeps sending. So it would be
possible to write some logic in SC to detect the right port on a first
message and then continue listening only to that port.
However, in my humble opinion, that is not the most pretty solution.
I did also propose a solution for listening to any port from a specific IP on
the dev list a few days ago, but I did not get any feedback on that yet.
> > OSC only defines a message exchange format, but a particular
> > application level protocol built on top of OSC might require
> > bidirectional communication to communicate state changes.
>
> i totally agree.
> i just commented on marije's "in OSC it is custom to send a reply"
> which it is not (imho). remove the O and i will agree to "in SC it is
> custom to send a reply".
Actually, here I relied on what my fellow programmers at the TU Berlin taught
me. I then faithfully adapted my code to use the send_from functions in
liblo.
After all I am just a physicist, not a trained IT person. ;)
> if it is _required_ to follow this custom (instead of being optional)
> in order to make a communication with a certain application work, than
> the docs should clearly say so (which they might do anyhow;
> unfortunately, i cannot check now)
In SC it is optional (you can set the NetAddr to nil in the responder), but a
request was made to make it more specific.
Now there are a number of solutions:
* detect the port upon the first message and from there on only listen to that
port. Requires a bit of logic written in SC by the user.
* make use of the proposed arbitrary port solution for the responder (see
dev-list)
* convince the third-party application that their osc sending should include a
fixed and configurable port they send *from*.
> On 8 Mar 2008, at 20:45, zmoelnig@... wrote:
> > all udp implementations in Pd currently are unidirectional.
> > however, you can create a [udpsend] to port <xyz> and, in the same
> > patch, a [udpreceive] that listens at port <xyz>, which might help (or
> > not).
> > (it still would involve 2 independent sockets)
>
> I've tried using dumpOSC on port 57110 in order to get messages back
> from the SC server, but this object will not initialise as the server
> is already using the port.
dumpOSC tries to listen on the same port as the server, so if both are running
simultaneously this won't work.
> This is not a problem in the OSC implementations in Max. There you
> can send to and get data back from SC Server.
Yes, since Max listens to another port and sends from another port.
> > nevertheless, somebody could write a bi-directional udp object, which
> > should do no harm :-)
>
> For Pd users that want to communicate to SC Synth this would be good.
Max users too...
> ----- Original Message -----
> From: thor <th.list@...>
> To: "SuperCollider users mailing list" <sc-users@...>
> Subject: Re: [sc-users] NetAddr
> Date: Sat, 8 Mar 2008 21:44:46 +0200
>
>
>
> Hi IOhannes
>
> On 8 Mar 2008, at 20:45, zmoelnig@... wrote:
>
> > all udp implementations in Pd currently are unidirectional.
> > however, you can create a [udpsend] to port <xyz> and, in the same
> > patch, a [udpreceive] that listens at port <xyz>, which might help (or
> > not).
> > (it still would involve 2 independent sockets)
>
> I've tried using dumpOSC on port 57110 in order to get messages back
> from the SC server, but this object will not initialise as the
> server is already
> using the port.
>
> This is not a problem in the OSC implementations in Max. There you
> can send to and get data back from SC Server.
>
> > nevertheless, somebody could write a bi-directional udp object, which
> > should do no harm :-)
>
> For Pd users that want to communicate to SC Synth this would be good.
>
> (unless I'm forgetting about something obvious).???
>
> thor
>
> _______________________________________________
> sc-users mailing list
> sc-users@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-users
> Sorry, I jumped into this thread late, so there's a chance that I
> misunderstand the issues, but...
>
>> This is not a problem in the OSC implementations in Max. There you
>> can send to and get data back from SC Server.
>
> Actually it's the same problem in Max-land:
>
> http://www.synthesisters.com/hypermail/max-msp/Sep07/73979.html
Sure, but it uses otudp, which I understand is not supported by cnmat any more (unless they've changed their minds). otudp is suppose to be replaced by udpsend and udpreceive, but udpsend doesn't have an outlet for messages sent to its port...
-Brian
> ----- Original Message -----
> From: thor <th.list@...>
> To: "SuperCollider users mailing list" <sc-users@...>
> Subject: Re: [sc-users] NetAddr
> Date: Sat, 8 Mar 2008 23:20:00 +0200
>
>
>
> On 8 Mar 2008, at 22:24, Brian Willkie wrote:
>
> > Sorry, I jumped into this thread late, so there's a chance that I
> > misunderstand the issues, but...
> >
> >> This is not a problem in the OSC implementations in Max. There you
> >> can send to and get data back from SC Server.
> >
> > Actually it's the same problem in Max-land:
> >
> > http://www.synthesisters.com/hypermail/max-msp/Sep07/73979.html >
> Hi Brian,
>
> Does this work for you?
>
>
>
> max v2;
> #N vpatcher 224 44 1022 562;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 340 215 125 196617 set trigger rate of synth;
> #P number 299 214 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 299 233 109 196617 /n_set 1000 trate \$1;
> #P comment 271 358 77 196617 the frequency;
> #P comment 203 299 221 196617 the trigger message from the SendTrig
> UGen;
> #P window linecount 2;
> #P comment 409 356 94 196617 Max and SC playing happily together;
> #P flonum 311 407 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 365 353 34 0;
> #P window linecount 1;
> #P newex 260 435 41 196617 *~ 0.3;
> #P newex 260 473 31 196617 dac~;
> #P newex 260 409 46 196617 phasor~;
> #P number 230 357 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P number 144 352 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 144 327 97 196617 unpack 1000 0 440;
> #P newex 144 296 52 196617 route /tr;
> #P message 105 62 52 196617 /notify 1;
> #P toggle 15 91 15 0;
> #P newex 105 268 89 196617 OpenSoundControl;
> #P newex 105 162 27 196617 t b l;
> #P message 15 111 71 196617 /dumpOSC \$1;
> #P message 128 116 72 196617 /n_free 1000;
> #P message 130 90 255 196617 /s_new maxtrigger 1000 1 0 freq 333. amp
> 0.1 out 0;
> #P newex 105 201 89 196617 OpenSoundControl;
> #P newex 105 233 135 196617 otudp write localhost 57110;
> #P window linecount 8;
> #P comment 437 89 324 196617 SynthDef(maxtrigger \, { arg trate=4 \;
> var trig \, seq1 \, freq \; trig = Impulse.kr(trate) \; seq1 =
> SinOsc.ar(1.2 \, mul: 200 \, add: 700) \; freq = Demand.kr(trig \, 0
> \, seq1) \; SendTrig.kr(trig \, 0 \, freq) \; Out.ar(0 \, (SinOsc.ar
> (freq + [0 \, 0.7]).cubed.cubed * 0.1).dup) \; }).load(s) \;;
> #P window linecount 1;
> #P comment 167 63 184 196617 notify that Max/MSP is the client;
> #P window linecount 2;
> #P comment 439 57 303 196617 after /notify 1 this synthdef should
> send info back to the server if you have loaded it (you do that in sc-
> lang);
> #P connect 10 0 7 0;
> #P connect 11 0 8 0;
> #P connect 7 0 8 0;
> #P connect 5 0 8 0;
> #P connect 6 0 8 0;
> #P fasten 24 0 8 0 304 256 281 256 281 151 110 151;
> #P connect 8 1 4 0;
> #P connect 8 0 4 0;
> #P connect 4 0 3 0;
> #P connect 3 0 9 0;
> #P fasten 9 1 12 0 149 293 149 293;
> #P connect 12 0 13 0;
> #P connect 13 0 14 0;
> #P connect 13 2 15 0;
> #P fasten 15 0 16 0 235 405 265 405;
> #P connect 16 0 18 0;
> #P fasten 19 0 17 0 370 462 265 462;
> #P connect 18 0 17 0;
> #P connect 18 0 17 1;
> #P connect 20 0 18 1;
> #P connect 25 0 24 0;
> #P pop;
>
>
>
> _______________________________________________
> sc-users mailing list
> sc-users@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-users
Sure, but it uses otudp, which I understand is not supported by cnmat any more (unless they've changed their minds). otudp is suppose to be replaced by udpsend and udpreceive, but udpsend doesn't have an outlet for messages sent to its port...
I see, we should convince them to support this in udpsend.
Otherwise, we have no chance of getting stuff back from the server???
On Sunday 09 March 2008 14:01:36 IOhannes m zmölnig wrote:
> >> i would say that this makes it clear that no assumption should be made
> >> that the sender and receiver port ought to be the same.
> >>
> >>
> >> and it makes perfect sense, e.g. if you have two clients on the same
> >> machine communicating with one server, you probably want to be able to
> >> discriminate them (without having to open 2 ports on the server!)
> >
> > I don't see your argument here.
> > We agree on this. The server listens on one port only. The clients send
> > from different ports, since they cannot use the same port.
>
> probably i got confused as i seem to remember that SC wants to respond
> to the same port as it listens to (sender port == receiver port).
> but this might be my inaccurate reading.
It is the whole confusion that I try to clear up in this thread.
SC sends *from* the same port as it listens on. It can send *to* any port.
> > It is more that in order to be sure that messages come from the right
> > client, important in open, i.e. running over an open network,
> > configuration, that the
>
> so is this "feature" of SC a security mechanism or a client dispatching
> mechanism?
Well, you can see it however you like.
SC has the option to listen to messages coming *from* one specific IP and
port. You can call that a security mechanism or client dispatching.
All the messages send to SC's port will be reacted upon, it just depends
whether there is a matching responder or not, whether or not a message is
discarded or used to execute some code.
> > I did also propose a solution for listening to any port from a specific
> > IP on the dev list a few days ago, but I did not get any feedback on that
> > yet.
>
> and probably allow netmasks for the IP too (if that is not already
> possible)
that seems to be an interesting idea.
> > In SC it is optional (you can set the NetAddr to nil in the responder),
> > but a request was made to make it more specific.
> > Now there are a number of solutions:
> >
> > * detect the port upon the first message and from there on only listen to
> > that port. Requires a bit of logic written in SC by the user.
> > * make use of the proposed arbitrary port solution for the responder (see
> > dev-list)
>
> i have briefly looked at the archives of sc-dev but haven't been able to
> find a reference to this.
the list has been sc-devel since sc-dev stopped working properly.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
