Re: oscit registration complete !

[Jeff Glatt]

Questions about oscit:

1) Why is it limited to UDP?

2) Why do you need the /.reply_to message? A UDP datagram includes the
sender's reply address, so you just pull that out of the UDP datagram if you
want to reply. So too, you can get the sender's address from a TCP (ie,
connected) socket. I imagine that most other multi-bus protocols include the
sender information with any "message", for example, with USB. So why don't
you just leave it up to the underlying protocol to supply the sender's
address (in the same way that OSC itself leaves it up to the underlying
protocol to supply the size of each received OSC message)?

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Gaspard Bucher]

On Wed, Jan 28, 2009 at 4:37 AM, Jeff Glatt <jgglatt@...> wrote:
> Questions about oscit:
>
> 1) Why is it limited to UDP?
UDP is a first step. Network protocols are the only ones that enable
zero configuration (plug & play) for the moment so this is the
priority. All other connections can be handled through an application
that acts as proxy.

>
> 2) Why do you need the /.reply_to message? A UDP datagram includes the
> sender's reply address, so you just pull that out of the UDP datagram if you
> want to reply. So too, you can get the sender's address from a TCP (ie,
> connected) socket. I imagine that most other multi-bus protocols include the
> sender information with any "message", for example, with USB. So why don't
> you just leave it up to the underlying protocol to supply the sender's
> address (in the same way that OSC itself leaves it up to the underlying
> protocol to supply the size of each received OSC message)?
Because it doesn't work ! Most implementations of OSC I have tried do
not let you define the outgoing port when creating a connection. This
means packets are sent with something like "10.0.0.5:90002" and
sending messages back to this IP:port pair is of no use because the
application does not listen at this port. The obvious solution to
ignore "/.reply_to" is to use mdns to get the reply port of an IP. But
even this solution would break when you have multiple applications at
the same IP.

I don't like the "/.reply_to" thing and will do my best to get rid of
it, but I am afraid it will have to stay...

Gaspard
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Glatt]

>Because it doesn't work ! Most implementations of OSC I have
>tried do not let you define the outgoing port when creating a
>connection.

Oh dear. Are you writing your own software? If so, then try my
new EasyOSC lib. It saves the sender's address with every received
UDP or TCP message. You don't even need to know what that
address is. To reply to a message you receive, you just call the
function OscReplyMsg, and EasyOSC takes care of sending it to
the right device.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Gaspard Bucher]

>>Because it doesn't work ! Most implementations of OSC I have
>>tried do not let you define the outgoing port when creating a
>>connection.
>
> Oh dear. Are you writing your own software? If so, then try my
> new EasyOSC lib. It saves the sender's address with every received
> UDP or TCP message. You don't even need to know what that
> address is. To reply to a message you receive, you just call the
> function OscReplyMsg, and EasyOSC takes care of sending it to
> the right device.

When I talk about "implementations" I don't mean "osc library", but
real world applications with OSC support that need to be supported one
way or the other (max/MSP for example). I haven't tested EasyOSC with
max/MSP though but I doubt it would work since "oscsend" and
"oscreceive" are two different and agnostic objects and you have *no*
way to define the outgoing port of an "udpsend" object.
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Glatt]

>When I talk about "implementations" I don't mean "osc library", but
>real world applications with OSC support that need to be supported one
>way or the other (max/MSP for example).

Ok, I gather that you're writing your own app (which you want to
communicate with max/MSP), so whatever you come up with for
oscit _must_ work with max/MSP (as it exists today).

Got it.

>I haven't tested EasyOSC with max/MSP though but I doubt it
>would work since "oscsend" and "oscreceive" are two different
>and agnostic objects

Ok, I'm not familiar with max/MSP specifically. (Sorry, not a Mac
guy. Linux and Windows here). But I gather that these are some
sort of "exposed software interfaces" that a separate app like yours
can "connect" to?

>you have *no* way to define the outgoing port of an "udpsend"
>object.

>From within max/MSP, I gather? But surely it must know what UDP
port to send a message to your app? How does it  determine what
UDP port you're using? It just can't pick its own, random number.

To get more familiar with what you're doing, I did a search for
"max/msp udpsend" and I came up with a URL to a message on
this very list:

http://opensoundcontrol.org/topic/222

In one of the replies someone mentions "enter IP and Port for your
udpsend object via Text/Number boxes with prepended host and port".
Are you sure what you want to do is not possible? Or is this
incorrect/outdated info?
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Gaspard Bucher]

I do not want to dive too deeply into max/MSP, but to be brief: it's a
very common tool used by artists and I'm writing http://rubyk.org as
an open source replacement for most of the tasks max/MSP is doing. But
since max/MSP is so common in the field I'm working in (live
performance art, installations), I have to live with what it does.

udpsend object setup
-----------------------------

This object is really stupid: it sends whatever data you feed it to a
specific ip end point specified by IP and port:

[udpsend 10.0.0.5 7400]  -----> other app listening at 10.0.0.5:7400

The port specified here is the target's port. When receiving messages
in "other app", the sender's port (max/MSP) can be anything (50173 for
a typical value). You cannot open any "udpreceive" with this port
(already in use) and what you send it is ignored.

If you want to try it out, there's a demo windows version of max/MSP:
http://www.cycling74.com/downloads/max5

Gaspard

On Wed, Jan 28, 2009 at 10:17 AM, Jeff Glatt <jgglatt@...> wrote:

>>When I talk about "implementations" I don't mean "osc library", but
>>real world applications with OSC support that need to be supported one
>>way or the other (max/MSP for example).
>
> Ok, I gather that you're writing your own app (which you want to
> communicate with max/MSP), so whatever you come up with for
> oscit _must_ work with max/MSP (as it exists today).
>
> Got it.
>
>>I haven't tested EasyOSC with max/MSP though but I doubt it
>>would work since "oscsend" and "oscreceive" are two different
>>and agnostic objects
>
> Ok, I'm not familiar with max/MSP specifically. (Sorry, not a Mac
> guy. Linux and Windows here). But I gather that these are some
> sort of "exposed software interfaces" that a separate app like yours
> can "connect" to?
>
>>you have *no* way to define the outgoing port of an "udpsend"
>>object.
>
> >From within max/MSP, I gather? But surely it must know what UDP
> port to send a message to your app? How does it  determine what
> UDP port you're using? It just can't pick its own, random number.
>
> To get more familiar with what you're doing, I did a search for
> "max/msp udpsend" and I came up with a URL to a message on
> this very list:
>
> http://opensoundcontrol.org/topic/222
>
> In one of the replies someone mentions "enter IP and Port for your
> udpsend object via Text/Number boxes with prepended host and port".
> Are you sure what you want to do is not possible? Or is this
> incorrect/outdated info?
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[salsaman-3]

On Wed, January 28, 2009 04:37, Jeff Glatt wrote:

> Questions about oscit:
>
> 1) Why is it limited to UDP?
>
> 2) Why do you need the /.reply_to message? A UDP datagram includes the
> sender's reply address, so you just pull that out of the UDP datagram if
> you
> want to reply. So too, you can get the sender's address from a TCP (ie,
> connected) socket. I imagine that most other multi-bus protocols include
> the
> sender information with any "message", for example, with USB. So why don't
> you just leave it up to the underlying protocol to supply the sender's
> address (in the same way that OSC itself leaves it up to the underlying
> protocol to supply the size of each received OSC message)?
>

Sender and receiver may be different applications, on different
ports/hosts. Unlikely, but why limit yourself ?

Salsaman.


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[salsaman-3]

On Wed, January 28, 2009 04:37, Jeff Glatt wrote:

> Questions about oscit:
>
> 1) Why is it limited to UDP?
>
> 2) Why do you need the /.reply_to message? A UDP datagram includes the
> sender's reply address, so you just pull that out of the UDP datagram if
> you
> want to reply. So too, you can get the sender's address from a TCP (ie,
> connected) socket. I imagine that most other multi-bus protocols include
> the
> sender information with any "message", for example, with USB. So why don't
> you just leave it up to the underlying protocol to supply the sender's
> address (in the same way that OSC itself leaves it up to the underlying
> protocol to supply the size of each received OSC message)?
>

Answer b). You might not want replies at all, the sender might not be
capable of listening, in which case you will be needlessly filling a send
buffer.


Answer c) in future we might want to support multiple listeners.

Salsaman.


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Glatt]

>The port specified here is the target's port. When receiving messages
>in "other app", the sender's port (max/MSP) can be anything (50173 for
>a typical value). You cannot open any "udpreceive" with this port
>(already in use) and what you send it is ignored.

Aha! I think I got it!

When max/MSP sends a UDP datagram to some other port (using
the berkeley sockets function sendto), it creates a brand new socket
and specifies that socket as the one sending the message. (ie, It passes
that new socket as the first arg to sendto). Then it apparently closes
that socket after sending the message, instead of listening for replies
on that socket.

This should be a simple fix to max/MSP. Is there any msx/MSP
developer on this list? If so, you could make a suggested extension
to their udpsend object. What you want to do is be able to pass
an additional arg when creating one of these udpsend objects.
The additional arg is the port number of one of your udpreceive
objects, like this:

[udpreceive 10000]
[udpsend 10.0.0.5 7400 10000]

That should work a charm.

I'm finding it very difficult to find good documentation about what
exactly these updreceive and udpsend "objects" are. I gather that
they are some sort of "plug-in" in the form of a dynamic link library
(or "shared library" in Linux lingo) that max/MSP opens/uses. If so,
and there's source code available, point me to it. I'll take a peek at
it. I can't imagine that it would take long to modify it to provide the
feature you need.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Andy W. Schmeder-2]

On Jan 28, 2009, at 1:47 AM, Gaspard Bucher wrote:

> But since max/MSP is so common in the field I'm working in (live
> performance art, installations), I have to live with what it does.

There is a some chance that the functionality will be added to udpsend/
udpreceive.  I've been complaining about it for a long time...  there  
is no technical reason it can't be done.

Someone at CNMAT has a connection with Cycling that includes access to  
source code of some objects--this is one of them.  It is possible that  
it gets fixed and even merged into the mainstream max distribution.  
Even more likely if other OSC libraries and applications also start  
supporting bidirectional UDP (many still do not).

Also max comes with some fairly competent networking objects written  
in java--including the source code: net.udp.recv, net.udp.send.  What  
is needed is net.udp.recvfrom and net.udp.sendto.


---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Sciss-3]

Am 28.01.2009 um 19:13 schrieb Andy W. Schmeder:

> On Jan 28, 2009, at 1:47 AM, Gaspard Bucher wrote:
>
>> But since max/MSP is so common in the field I'm working in (live
>> performance art, installations), I have to live with what it does.
>
> There is a some chance that the functionality will be added to  
> udpsend/
> udpreceive.  I've been complaining about it for a long time...  there
> is no technical reason it can't be done.
>
> Someone at CNMAT has a connection with Cycling that includes access to
> source code of some objects--this is one of them.  It is possible that
> it gets fixed and even merged into the mainstream max distribution.
> Even more likely if other OSC libraries and applications also start
> supporting bidirectional UDP (many still do not).
>
> Also max comes with some fairly competent networking objects written
> in java--including the source code: net.udp.recv, net.udp.send.  What
> is needed is net.udp.recvfrom and net.udp.sendto.

check this out

http://maxobjects.com/?v=objects&id_objet=3733

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Gaspard Bucher]

Thanks for the link. Good to know bidirectional OSC is available to
max/msp. This also means that the "/.reply_to" is no longer needed.

Please tell me if there are any other reasons to keep "/.reply_to" or
I will remove it from oscit's draft.

What about observers (something that needs to get notified when a
value changes so the slider is kept in sync for example) ?

Should an observer receive all return values => observe everything ?

Should it only observe a list of urls ?

Gaspard

On Wed, Jan 28, 2009 at 9:36 PM, Sciss <contact@...> wrote:

> Am 28.01.2009 um 19:13 schrieb Andy W. Schmeder:
>
>> On Jan 28, 2009, at 1:47 AM, Gaspard Bucher wrote:
>>
>>> But since max/MSP is so common in the field I'm working in (live
>>> performance art, installations), I have to live with what it does.
>>
>> There is a some chance that the functionality will be added to
>> udpsend/
>> udpreceive.  I've been complaining about it for a long time...  there
>> is no technical reason it can't be done.
>>
>> Someone at CNMAT has a connection with Cycling that includes access to
>> source code of some objects--this is one of them.  It is possible that
>> it gets fixed and even merged into the mainstream max distribution.
>> Even more likely if other OSC libraries and applications also start
>> supporting bidirectional UDP (many still do not).
>>
>> Also max comes with some fairly competent networking objects written
>> in java--including the source code: net.udp.recv, net.udp.send.  What
>> is needed is net.udp.recvfrom and net.udp.sendto.
>
> check this out
>
> http://maxobjects.com/?v=objects&id_objet=3733
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Martin Peach]

I'm already using a "/replyto" to specify the port to reply to so that
several identical receivers can be attached to the same sender and their
replies don't get mixed up. In my implementation (which works with both
Max/MSP and PureData) a device broadcasts an "/awake" message with its
IP as payload until the sender sends it a "/replyto".

Martin


Gaspard Bucher wrote:

> Thanks for the link. Good to know bidirectional OSC is available to
> max/msp. This also means that the "/.reply_to" is no longer needed.
>
> Please tell me if there are any other reasons to keep "/.reply_to" or
> I will remove it from oscit's draft.
>
> What about observers (something that needs to get notified when a
> value changes so the slider is kept in sync for example) ?
>
> Should an observer receive all return values => observe everything ?
>
> Should it only observe a list of urls ?
>
> Gaspard
>
> On Wed, Jan 28, 2009 at 9:36 PM, Sciss <contact@...> wrote:
>> Am 28.01.2009 um 19:13 schrieb Andy W. Schmeder:
>>
>>> On Jan 28, 2009, at 1:47 AM, Gaspard Bucher wrote:
>>>
>>>> But since max/MSP is so common in the field I'm working in (live
>>>> performance art, installations), I have to live with what it does.
>>> There is a some chance that the functionality will be added to
>>> udpsend/
>>> udpreceive.  I've been complaining about it for a long time...  there
>>> is no technical reason it can't be done.
>>>
>>> Someone at CNMAT has a connection with Cycling that includes access to
>>> source code of some objects--this is one of them.  It is possible that
>>> it gets fixed and even merged into the mainstream max distribution.
>>> Even more likely if other OSC libraries and applications also start
>>> supporting bidirectional UDP (many still do not).
>>>
>>> Also max comes with some fairly competent networking objects written
>>> in java--including the source code: net.udp.recv, net.udp.send.  What
>>> is needed is net.udp.recvfrom and net.udp.sendto.
>> check this out
>>
>> http://maxobjects.com/?v=objects&id_objet=3733
>>
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev@...
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[salsaman-3]

On Thu, January 29, 2009 00:04, Gaspard Bucher wrote:

> Thanks for the link. Good to know bidirectional OSC is available to
> max/msp. This also means that the "/.reply_to" is no longer needed.
>
> Please tell me if there are any other reasons to keep "/.reply_to" or
> I will remove it from oscit's draft.
>
> What about observers (something that needs to get notified when a
> value changes so the slider is kept in sync for example) ?
>
> Should an observer receive all return values => observe everything ?
>
> Should it only observe a list of urls ?
>
> Gaspard

The way I had envisaged this for LiVES is that an observer gets everything
by default, but it is possible to turn off certain notifications using
some kind of bitmask. Thus the host would maintain a matrix of notify
addresses versus events to notify.

So for example:

/notify_to [host] port [bitmask]

However, the problem is, what do these events represent ? For example, in
LiVES there are enumerated events like "video frame synch", "new clip
available", "clip closed" and "application exit". One solution might be to
create a common list (enumeration) of events. Also, with many event types,
the length of the bitmask to block events becomes increasingly silly.


Salsaman.
http://lives.sourceforge.net


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

On 28 Jan 2009, at 07:23, Gaspard Bucher wrote:

> On Wed, Jan 28, 2009 at 4:37 AM, Jeff Glatt <jgglatt@...>  
> wrote:
>> Questions about oscit:
>>
>> 1) Why is it limited to UDP?
> UDP is a first step. Network protocols are the only ones that enable
> zero configuration (plug & play) for the moment so this is the
> priority. All other connections can be handled through an application
> that acts as proxy.
>
>>
>> 2) Why do you need the /.reply_to message? A UDP datagram includes  
>> the
>> sender's reply address, so you just pull that out of the UDP  
>> datagram if you
>> want to reply. So too, you can get the sender's address from a TCP  
>> (ie,
>> connected) socket. I imagine that most other multi-bus protocols  
>> include the
>> sender information with any "message", for example, with USB. So  
>> why don't
>> you just leave it up to the underlying protocol to supply the  
>> sender's
>> address (in the same way that OSC itself leaves it up to the  
>> underlying
>> protocol to supply the size of each received OSC message)?
> Because it doesn't work ! Most implementations of OSC I have tried do
> not let you define the outgoing port when creating a connection. This
> means packets are sent with something like "10.0.0.5:90002" and
> sending messages back to this IP:port pair is of no use because the
> application does not listen at this port. The obvious solution to
> ignore "/.reply_to" is to use mdns to get the reply port of an IP. But
> even this solution would break when you have multiple applications at
> the same IP.
>
> I don't like the "/.reply_to" thing and will do my best to get rid of
> it, but I am afraid it will have to stay...

This was the original reason for the semantics of '/register' in  
Integra instead of '/reply_to', i.e. '/register' without any arguments  
can be interpreted as a *request for registration* in the context of a  
bi-directional transport. You are saying 'register me (the client) for  
replies'. '/reply_to' doesn't make any sense in the context of bi-
directional UDP because you're not supplying any arguments.

I do think we need a mechanism for clients to 'opt in'  to server  
responses. I therefore suggest we change '/reply_to' to '/register'  
and allow zero arguments:

/register       - register this client for replies in bi-
directional context
/register <port>   - register client on same host (address/port not  
in datagram)
/register <port> <ip address> - register client on remote host  
(address/port not in datagram)

This gives oscit the flexibility to support situations where the  
sender's reply address is encoded in the datagram or supplied by the  
client.

Jamie



Jamie


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[salsaman-3]

On Fri, January 30, 2009 17:28, Jamie Bullock wrote:

>
> On 28 Jan 2009, at 07:23, Gaspard Bucher wrote:
>
>> On Wed, Jan 28, 2009 at 4:37 AM, Jeff Glatt <jgglatt@...>
>> wrote:
>>> Questions about oscit:
>>>
>>> 1) Why is it limited to UDP?
>> UDP is a first step. Network protocols are the only ones that enable
>> zero configuration (plug & play) for the moment so this is the
>> priority. All other connections can be handled through an application
>> that acts as proxy.
>>
>>>
>>> 2) Why do you need the /.reply_to message? A UDP datagram includes
>>> the
>>> sender's reply address, so you just pull that out of the UDP
>>> datagram if you
>>> want to reply. So too, you can get the sender's address from a TCP
>>> (ie,
>>> connected) socket. I imagine that most other multi-bus protocols
>>> include the
>>> sender information with any "message", for example, with USB. So
>>> why don't
>>> you just leave it up to the underlying protocol to supply the
>>> sender's
>>> address (in the same way that OSC itself leaves it up to the
>>> underlying
>>> protocol to supply the size of each received OSC message)?
>> Because it doesn't work ! Most implementations of OSC I have tried do
>> not let you define the outgoing port when creating a connection. This
>> means packets are sent with something like "10.0.0.5:90002" and
>> sending messages back to this IP:port pair is of no use because the
>> application does not listen at this port. The obvious solution to
>> ignore "/.reply_to" is to use mdns to get the reply port of an IP. But
>> even this solution would break when you have multiple applications at
>> the same IP.
>>
>> I don't like the "/.reply_to" thing and will do my best to get rid of
>> it, but I am afraid it will have to stay...
>
> This was the original reason for the semantics of '/register' in
> Integra instead of '/reply_to', i.e. '/register' without any arguments
> can be interpreted as a *request for registration* in the context of a
> bi-directional transport. You are saying 'register me (the client) for
> replies'. '/reply_to' doesn't make any sense in the context of bi-
> directional UDP because you're not supplying any arguments.
>
> I do think we need a mechanism for clients to 'opt in'  to server
> responses. I therefore suggest we change '/reply_to' to '/register'
> and allow zero arguments:
>
> /register       - register this client for replies in bi-
> directional context
> /register <port>   - register client on same host (address/port not
> in datagram)
> /register <port> <ip address> - register client on remote host
> (address/port not in datagram)
>
> This gives oscit the flexibility to support situations where the
> sender's reply address is encoded in the datagram or supplied by the
> client.
>
> Jamie
>
>
>
> Jamie
>
>
>

Agree 100 %, except that others have requested that ip address parameter
should come before port. So we would have:

/register                                                - register this
client for replies in bi-
directional context
/register <port>                                  - register client on
same host (address/port not
in datagram)
/register <ip address> <port>         - register client on remote host
(address/port not in datagram)


Salsaman.
http://lives.sourceforge.net


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

On 30 Jan 2009, at 17:04, salsaman@... wrote:
<snip>

>
> Agree 100 %, except that others have requested that ip address  
> parameter
> should come before port. So we would have:
>
> /register                                                - register  
> this
> client for replies in bi-
> directional context
> /register <port>                                  - register client on
> same host (address/port not
> in datagram)
> /register <ip address> <port>         - register client on remote host
> (address/port not in datagram)

Fine with me, in fact that's how we already have it (http://wiki.integralive.org/lib:server 
).

best,

Jamie

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Joe Malloch]

>>
>> /register                                                - register
>> this
>> client for replies in bi-
>> directional context
>> /register <port>                                  - register client on
>> same host (address/port not
>> in datagram)
>> /register <ip address> <port>         - register client on remote host
>> (address/port not in datagram)
>
>
> Fine with me, in fact that's how we already have it (http://wiki.integralive.org/lib:server).

Also quite similar to the stuff we use here, except our system is
distributed so after negotiating for unique identifiers and ports a
device sends:

/device/registered <ip address> <port> <deviceClass> <numInputs> <numOutputs>

this is multicast on the "admin bus"

Joseph Malloch
Input Devices and Music Interaction Laboratory
Schulich School of Music - McGill University
email: joseph.malloch@...
web: http://www.music.mcgill.ca/~mallochj
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[salsaman-3]

On Fri, January 30, 2009 22:23, Joseph Malloch wrote:

>>>
>>> /register                                                - register
>>> this
>>> client for replies in bi-
>>> directional context
>>> /register <port>                                  - register client on
>>> same host (address/port not
>>> in datagram)
>>> /register <ip address> <port>         - register client on remote host
>>> (address/port not in datagram)
>>
>>
>> Fine with me, in fact that's how we already have it
>> (http://wiki.integralive.org/lib:server).
>
> Also quite similar to the stuff we use here, except our system is
> distributed so after negotiating for unique identifiers and ports a
> device sends:
>
> /device/registered <ip address> <port> <deviceClass> <numInputs>
> <numOutputs>
>
> this is multicast on the "admin bus"
>
> Joseph Malloch
> Input Devices and Music Interaction Laboratory
> Schulich School of Music - McGill University
> email: joseph.malloch@...
> web: http://www.music.mcgill.ca/~mallochj
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>

OK, since we all seem agreed on this, at least as a first step, I have
added it to the summary page:

http://openmediacontrol.wetpaint.com/page/summary


If we follow the numbering on the page, then the next question is - what
should /register return (if anything), and what should be the format of
the return.


For the latter I would strongly prefer all return values as plain text
(ASCII) for reasons that I have explained already.

Cheers,
Salsaman.
http://lives.sourceforge.net


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev