Csound has a OSCInit and a corresponding OSCListen.
It has a OSCsend, but no OSCConnect.
So OSCSend has to build a connection every time(a connect to the server),
resulting in some overhead and a different client IP address for each
connection.
I wonder if we could have a OSCConnect and a corresponding OSCCsend (OSC
Connected send - for example), that would probably be faster and neater.

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779.html
Sent from the Csound - General mailing list archive at Nabble.com.

Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
implementations have this.

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html
Sent from the Csound - General mailing list archive at Nabble.com.

The point is if you concern is efficiency, UDP is much more efficient *because* it doesn't have a persistent concept of a connection. There is no such concept in the UDP protocol.

It sounded like your initial concern was about overhead, which to me means issues of efficiency. The connection is an abstraction that is needed because of TCP. That is part of TCP's overhead.

Also, I am not sure what you mean by "the client getting a new IP address for each connection". The IP address is an operating system level configuration, and if you are connected to the network you have the address. There is no need to reconnect to send a new datagram. If you mean allocating a port, allocating a sending port is a TCP specific overhead (because one TCP connection is really a send and a receive bundled together, and really you are allocating the receive side needed to do things like get messages asking for things like the resending of lost or corrupted packets). UDP is truely one way, so you do not allocate a sending port, you simply send to a destination port.

On Sat, Feb 2, 2013 at 12:24 AM, zappfinger <zappfinger@gmail.com> wrote:

Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
implementations have this.

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html

Sent from the Csound - General mailing list archive at Nabble.com.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

In theory UDP is unreliable as there is no confirmation/resend mechanism
but my understanding is that with most modern networks this is very rarely
a problem.
==John ff

> I am appreciating all the insight that is being shared here.  Thanks!
>
> --------------------------------
> Dr. Richard Boulanger
> rboulanger@berklee.edu
> -----------------------------------
>
>
>
>
> On Feb 2, 2013, at 10:18 AM, Justin Smith  wrote:
>
>> Also, I don't want this to come across as hostile or pedantic, I am just
>> trying to clarify things.
>>
>> While there is no efficiency based reason to prefer TCP over UDP, if we
>> wanted to ensure accuracy and integrity of messages (rather than the
>> current priority of speed and lower latency), that would be a reason to
>> use TCP, and thus we would in fact want to be able to initialize and
>> then store a persistent connection to a server.
>>
>>
>> On Sat, Feb 2, 2013 at 7:11 AM, Justin Smith 
>> wrote:
>> The point is if you concern is efficiency, UDP is much more efficient
>> *because* it doesn't have a persistent concept of a connection. There is
>> no such concept in the UDP protocol.
>>
>> It sounded like your initial concern was about overhead, which to me
>> means issues of efficiency. The connection is an abstraction that is
>> needed because of TCP. That is part of TCP's overhead.
>>
>> Also, I am not sure what you mean by "the client getting a new IP
>> address for each connection". The IP address is an operating system
>> level configuration, and if you are connected to the network you have
>> the address. There is no need to reconnect to send a new datagram. If
>> you mean allocating a port, allocating a sending port is a TCP specific
>> overhead (because one TCP connection is really a send and a receive
>> bundled together, and really you are allocating the receive side needed
>> to do things like get messages asking for things like the resending of
>> lost or corrupted packets). UDP is truely one way, so you do not
>> allocate a sending port, you simply send to a destination port.
>>
>>
>> On Sat, Feb 2, 2013 at 12:24 AM, zappfinger 
>> wrote:
>> Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
>> implementations have this.
>>
>> Richard
>>
>>
>>
>> --
>> View this message in context:
>> http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>

The point is if you concern is efficiency, UDP is much more efficient *because* it doesn't have a persistent concept of a connection. There is no such concept in the UDP protocol.

It sounded like your initial concern was about overhead, which to me means issues of efficiency. The connection is an abstraction that is needed because of TCP. That is part of TCP's overhead.

Also, I am not sure what you mean by "the client getting a new IP address for each connection". The IP address is an operating system level configuration, and if you are connected to the network you have the address. There is no need to reconnect to send a new datagram. If you mean allocating a port, allocating a sending port is a TCP specific overhead (because one TCP connection is really a send and a receive bundled together, and really you are allocating the receive side needed to do things like get messages asking for things like the resending of lost or corrupted packets). UDP is truely one way, so you do not allocate a sending port, you simply send to a destination port.

On Sat, Feb 2, 2013 at 12:24 AM, zappfinger <zappfinger@gmail.com> wrote:

Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
implementations have this.

Richard



--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html

Sent from the Csound - General mailing list archive at Nabble.com.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

It does seem to be a problem with streaming audio over wireless 
connections, where the timing is critical and dropped packets are very 
audible. There the only solution appears to be to choose a clear channel.


Martin

On 2013-02-02 11:29, jpff@cs.bath.ac.uk wrote:
> In theory UDP is unreliable as there is no confirmation/resend mechanism
> but my understanding is that with most modern networks this is very rarely
> a problem.
> ==John ff
>
>> I am appreciating all the insight that is being shared here.  Thanks!
>>
>> --------------------------------
>> Dr. Richard Boulanger
>> rboulanger@berklee.edu
>> -----------------------------------
>>
>>
>>
>>
>> On Feb 2, 2013, at 10:18 AM, Justin Smith  wrote:
>>
>>> Also, I don't want this to come across as hostile or pedantic, I am just
>>> trying to clarify things.
>>>
>>> While there is no efficiency based reason to prefer TCP over UDP, if we
>>> wanted to ensure accuracy and integrity of messages (rather than the
>>> current priority of speed and lower latency), that would be a reason to
>>> use TCP, and thus we would in fact want to be able to initialize and
>>> then store a persistent connection to a server.
>>>
>>>
>>> On Sat, Feb 2, 2013 at 7:11 AM, Justin Smith 
>>> wrote:
>>> The point is if you concern is efficiency, UDP is much more efficient
>>> *because* it doesn't have a persistent concept of a connection. There is
>>> no such concept in the UDP protocol.
>>>
>>> It sounded like your initial concern was about overhead, which to me
>>> means issues of efficiency. The connection is an abstraction that is
>>> needed because of TCP. That is part of TCP's overhead.
>>>
>>> Also, I am not sure what you mean by "the client getting a new IP
>>> address for each connection". The IP address is an operating system
>>> level configuration, and if you are connected to the network you have
>>> the address. There is no need to reconnect to send a new datagram. If
>>> you mean allocating a port, allocating a sending port is a TCP specific
>>> overhead (because one TCP connection is really a send and a receive
>>> bundled together, and really you are allocating the receive side needed
>>> to do things like get messages asking for things like the resending of
>>> lost or corrupted packets). UDP is truely one way, so you do not
>>> allocate a sending port, you simply send to a destination port.
>>>
>>>
>>> On Sat, Feb 2, 2013 at 12:24 AM, zappfinger 
>>> wrote:
>>> Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
>>> implementations have this.
>>>
>>> Richard
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>

But they're discussing OSC, not audio. I think OSC is fine over wireless.
On 2 Feb 2013, at 17:23, Martin Peach wrote:

> 
> It does seem to be a problem with streaming audio over wireless connections, where the timing is critical and dropped packets are very audible. There the only solution appears to be to choose a clear channel.
> 
> 
> Martin
> 
> On 2013-02-02 11:29, jpff@cs.bath.ac.uk wrote:
>> In theory UDP is unreliable as there is no confirmation/resend mechanism
>> but my understanding is that with most modern networks this is very rarely
>> a problem.
>> ==John ff
>> 
>>> I am appreciating all the insight that is being shared here.  Thanks!
>>> 
>>> --------------------------------
>>> Dr. Richard Boulanger
>>> rboulanger@berklee.edu
>>> -----------------------------------
>>> 
>>> 
>>> 
>>> 
>>> On Feb 2, 2013, at 10:18 AM, Justin Smith  wrote:
>>> 
>>>> Also, I don't want this to come across as hostile or pedantic, I am just
>>>> trying to clarify things.
>>>> 
>>>> While there is no efficiency based reason to prefer TCP over UDP, if we
>>>> wanted to ensure accuracy and integrity of messages (rather than the
>>>> current priority of speed and lower latency), that would be a reason to
>>>> use TCP, and thus we would in fact want to be able to initialize and
>>>> then store a persistent connection to a server.
>>>> 
>>>> 
>>>> On Sat, Feb 2, 2013 at 7:11 AM, Justin Smith 
>>>> wrote:
>>>> The point is if you concern is efficiency, UDP is much more efficient
>>>> *because* it doesn't have a persistent concept of a connection. There is
>>>> no such concept in the UDP protocol.
>>>> 
>>>> It sounded like your initial concern was about overhead, which to me
>>>> means issues of efficiency. The connection is an abstraction that is
>>>> needed because of TCP. That is part of TCP's overhead.
>>>> 
>>>> Also, I am not sure what you mean by "the client getting a new IP
>>>> address for each connection". The IP address is an operating system
>>>> level configuration, and if you are connected to the network you have
>>>> the address. There is no need to reconnect to send a new datagram. If
>>>> you mean allocating a port, allocating a sending port is a TCP specific
>>>> overhead (because one TCP connection is really a send and a receive
>>>> bundled together, and really you are allocating the receive side needed
>>>> to do things like get messages asking for things like the resending of
>>>> lost or corrupted packets). UDP is truely one way, so you do not
>>>> allocate a sending port, you simply send to a destination port.
>>>> 
>>>> 
>>>> On Sat, Feb 2, 2013 at 12:24 AM, zappfinger 
>>>> wrote:
>>>> Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
>>>> implementations have this.
>>>> 
>>>> Richard
>>>> 
>>>> 
>>>> 
>>>> --
>>>> View this message in context:
>>>> http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>> 
>>>> 
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>> 
>>> 
>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>> 
>> 
>> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

I am hoping that you are all planning on collaborating on a fantastic article for The Csound Journal on all this!  We need it collected in one place, fully documented and with lots of example .csds that showcase all of your insights and approaches here.

-dB

--------------------------------

Dr. Richard Boulanger

rboulanger@berklee.edu

-----------------------------------

On Feb 2, 2013, at 12:44 PM, Justin Smith <noisesmith@gmail.com> wrote:

Modulo the congestion issues caused by the greater data volume you typically see with audio, OSC is exactly as prone to packet loss over wireless as audio data is. A noisy channel (like a crowded wifi band or a poor quality cable) is exactly when the problems with UDP tend to show up.

On Sat, Feb 2, 2013 at 9:32 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

But they're discussing OSC, not audio. I think OSC is fine over wireless.

On 2 Feb 2013, at 17:23, Martin Peach wrote:

>
> It does seem to be a problem with streaming audio over wireless connections, where the timing is critical and dropped packets are very audible. There the only solution appears to be to choose a clear channel.
>
>
> Martin
>
> On 2013-02-02 11:29, jpff@cs.bath.ac.uk wrote:
>> In theory UDP is unreliable as there is no confirmation/resend mechanism
>> but my understanding is that with most modern networks this is very rarely
>> a problem.
>> ==John ff
>>
>>> I am appreciating all the insight that is being shared here.  Thanks!
>>>
>>> --------------------------------
>>> Dr. Richard Boulanger
>>> rboulanger@berklee.edu
>>> -----------------------------------
>>>
>>>
>>>
>>>
>>> On Feb 2, 2013, at 10:18 AM, Justin Smith <noisesmith@gmail.com> wrote:
>>>
>>>> Also, I don't want this to come across as hostile or pedantic, I am just
>>>> trying to clarify things.
>>>>
>>>> While there is no efficiency based reason to prefer TCP over UDP, if we
>>>> wanted to ensure accuracy and integrity of messages (rather than the
>>>> current priority of speed and lower latency), that would be a reason to
>>>> use TCP, and thus we would in fact want to be able to initialize and
>>>> then store a persistent connection to a server.
>>>>
>>>>
>>>> On Sat, Feb 2, 2013 at 7:11 AM, Justin Smith <noisesmith@gmail.com>
>>>> wrote:
>>>> The point is if you concern is efficiency, UDP is much more efficient
>>>> *because* it doesn't have a persistent concept of a connection. There is
>>>> no such concept in the UDP protocol.
>>>>
>>>> It sounded like your initial concern was about overhead, which to me
>>>> means issues of efficiency. The connection is an abstraction that is
>>>> needed because of TCP. That is part of TCP's overhead.
>>>>
>>>> Also, I am not sure what you mean by "the client getting a new IP
>>>> address for each connection". The IP address is an operating system
>>>> level configuration, and if you are connected to the network you have
>>>> the address. There is no need to reconnect to send a new datagram. If
>>>> you mean allocating a port, allocating a sending port is a TCP specific
>>>> overhead (because one TCP connection is really a send and a receive
>>>> bundled together, and really you are allocating the receive side needed
>>>> to do things like get messages asking for things like the resending of
>>>> lost or corrupted packets). UDP is truely one way, so you do not
>>>> allocate a sending port, you simply send to a destination port.
>>>>
>>>>
>>>> On Sat, Feb 2, 2013 at 12:24 AM, zappfinger <zappfinger@gmail.com>
>>>> wrote:
>>>> Yes, I know. So we would need OSC over TCP to accomplish this. Many OSC
>>>> implementations have this.
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Slightly tangentially, but I know the Virginia Tech laptop orchestra
abandoned wreess communication for wires on similar grounds -- packet loss
or unpredctable delays.

just goes to show that one cannot wn them all

> I recently performed a piece using data from a physics sim in Jitter on
> one machine sending collision, velocity, and position xyz data for 8
> bodies over UDP to two machines running Max and Csound.
>
> When done wirelessly, there was some packet loss, but wired, the system
> reported no dropped packets and I was sending datagrams at about 10ms
> intervals.  Pretty solid.
>
> We were just tapping the streams of data though.  To send more orderly
> instantaneous data, particularly analysis data and things that need
> accuracy and a definite framerate, TCP would be desirable though.
>
> Just weighing in, based on recent experience...
>
> John Clements
>
> cell: 401-835-6050
> http://www.clementsaudio.com
>
>
> On Feb 2, 2013, at 9:58 AM, Richard Boulanger 
> wrote:
>
>> I am hoping that you are all planning on collaborating on a fantastic
>> article for The Csound Journal on all this!  We need it collected in one
>> place, fully documented and with lots of example .csds that showcase all
>> of your insights and approaches here.
>>
>> -dB
>>
>> --------------------------------
>> Dr. Richard Boulanger
>> rboulanger@berklee.edu
>> -----------------------------------
>>
>>
>>
>>
>> On Feb 2, 2013, at 12:44 PM, Justin Smith  wrote:
>>
>>> Modulo the congestion issues caused by the greater data volume you
>>> typically see with audio, OSC is exactly as prone to packet loss over
>>> wireless as audio data is. A noisy channel (like a crowded wifi band or
>>> a poor quality cable) is exactly when the problems with UDP tend to
>>> show up.
>>>
>>>
>>> On Sat, Feb 2, 2013 at 9:32 AM, Victor Lazzarini
>>>  wrote:
>>>> But they're discussing OSC, not audio. I think OSC is fine over
>>>> wireless.
>>>> On 2 Feb 2013, at 17:23, Martin Peach wrote:
>>>>
>>>> >
>>>> > It does seem to be a problem with streaming audio over wireless
>>>> connections, where the timing is critical and dropped packets are
>>>> very audible. There the only solution appears to be to choose a
>>>> clear channel.
>>>> >
>>>> >
>>>> > Martin
>>>> >
>>>> > On 2013-02-02 11:29, jpff@cs.bath.ac.uk wrote:
>>>> >> In theory UDP is unreliable as there is no confirmation/resend
>>>> mechanism
>>>> >> but my understanding is that with most modern networks this is very
>>>> rarely
>>>> >> a problem.
>>>> >> ==John ff
>>>> >>
>>>> >>> I am appreciating all the insight that is being shared here.
>>>> Thanks!
>>>> >>>
>>>> >>> --------------------------------
>>>> >>> Dr. Richard Boulanger
>>>> >>> rboulanger@berklee.edu
>>>> >>> -----------------------------------
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Feb 2, 2013, at 10:18 AM, Justin Smith 
>>>> wrote:
>>>> >>>
>>>> >>>> Also, I don't want this to come across as hostile or pedantic, I
>>>> am just
>>>> >>>> trying to clarify things.
>>>> >>>>
>>>> >>>> While there is no efficiency based reason to prefer TCP over UDP,
>>>> if we
>>>> >>>> wanted to ensure accuracy and integrity of messages (rather than
>>>> the
>>>> >>>> current priority of speed and lower latency), that would be a
>>>> reason to
>>>> >>>> use TCP, and thus we would in fact want to be able to initialize
>>>> and
>>>> >>>> then store a persistent connection to a server.
>>>> >>>>
>>>> >>>>
>>>> >>>> On Sat, Feb 2, 2013 at 7:11 AM, Justin Smith
>>>> 
>>>> >>>> wrote:
>>>> >>>> The point is if you concern is efficiency, UDP is much more
>>>> efficient
>>>> >>>> *because* it doesn't have a persistent concept of a connection.
>>>> There is
>>>> >>>> no such concept in the UDP protocol.
>>>> >>>>
>>>> >>>> It sounded like your initial concern was about overhead, which to
>>>> me
>>>> >>>> means issues of efficiency. The connection is an abstraction that
>>>> is
>>>> >>>> needed because of TCP. That is part of TCP's overhead.
>>>> >>>>
>>>> >>>> Also, I am not sure what you mean by "the client getting a new IP
>>>> >>>> address for each connection". The IP address is an operating
>>>> system
>>>> >>>> level configuration, and if you are connected to the network you
>>>> have
>>>> >>>> the address. There is no need to reconnect to send a new
>>>> datagram. If
>>>> >>>> you mean allocating a port, allocating a sending port is a TCP
>>>> specific
>>>> >>>> overhead (because one TCP connection is really a send and a
>>>> receive
>>>> >>>> bundled together, and really you are allocating the receive side
>>>> needed
>>>> >>>> to do things like get messages asking for things like the
>>>> resending of
>>>> >>>> lost or corrupted packets). UDP is truely one way, so you do not
>>>> >>>> allocate a sending port, you simply send to a destination port.
>>>> >>>>
>>>> >>>>
>>>> >>>> On Sat, Feb 2, 2013 at 12:24 AM, zappfinger
>>>> 
>>>> >>>> wrote:
>>>> >>>> Yes, I know. So we would need OSC over TCP to accomplish this.
>>>> Many OSC
>>>> >>>> implementations have this.
>>>> >>>>
>>>> >>>> Richard
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> View this message in context:
>>>> >>>> http://csound.1045644.n5.nabble.com/Csound-OSC-implementation-tp5719779p5719789.html
>>>> >>>> Sent from the Csound - General mailing list archive at
>>>> Nabble.com.
>>>> >>>>
>>>> >>>>
>>>> >>>> Send bugs reports to the Sourceforge bug tracker
>>>> >>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> >>>> Discussions of bugs and features can be posted here
>>>> >>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> >>>> csound"
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>> Send bugs reports to the Sourceforge bug tracker
>>>> >>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> >>> Discussions of bugs and features can be posted here
>>>> >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> >>> csound"
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> Send bugs reports to the Sourceforge bug tracker
>>>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> >> Discussions of bugs and features can be posted here
>>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > Send bugs reports to the Sourceforge bug tracker
>>>> >           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> > Discussions of bugs and features can be posted here
>>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>> >
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>