liblo-devel Mailing List for LibLO

On Wed, Jan 28, 2009 at 5:14 AM, alex <al...@sl...> wrote:
>
> Here's Dominic Sacré's change to lo_timetag_diff in patch form, which
> fixes bundle scheduling finally.
>
> Any chance of getting this and my lo_message_get_timestamp patch applied
> in svn?

Thanks!  Sorry, I've been delaying because I have some major deadlines
for next week at school.  I'll get back to liblo as soon as I can and
submit your patches, and then try to prepare a release.

cheers,

Steve

Here's Dominic Sacré's change to lo_timetag_diff in patch form, which
fixes bundle scheduling finally.

Any chance of getting this and my lo_message_get_timestamp patch applied
in svn?

cheers

alex

On Fri, Jan 23, 2009 at 7:50 PM, Mike Wozniewski <mi...@mi...> wrote:
> Hi Steve,
>
> I think I found the reason... and it seems to be an confusion with the
> programming interface issue for liblo.
>
> I tried checking if the SO_BROADCAST flag was set just before the data
> is sent in send_data() using getsockopt(), and it's NOT!
>
> This is because my data is actually being sent using a different socket.
> See this:
>
>    // Re-use existing socket?
>    if (from) {
>        sock = from->socket;
>    } else if (a->protocol == LO_UDP && lo_client_sockets.udp!=-1) {
>        sock = lo_client_sockets.udp;
>    } else {
>        if (a->socket==-1) {
>            ret = create_socket( a );
>            if (ret) return ret;
>        }
>        sock = a->socket;
>    }
>


Yeah, this lo_client_sockets data structure is a bit unfortunate IMHO,
though I see that it was put there to solve a problem.  But it's one
of the only global pieces of information that liblo uses.  I've toyed
with it before to see if there's a way to get rid of this global
reference but haven't come up with anything concrete.  I think it
could indeed cause problems for programs that have multiple servers,
and it looks like you found one case.


Steve

Ah. Thanks Nick. The lo_server_get_socket_fd() function helps.

So to wrap up, here is my workaround solution:

  string port = "9090"
  string addr = "10.10.10.255";
  broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
  lo_server broadcastServ = lo_server_new_with_proto(NULL, LO_UDP, oscParser_error);
  int sock = lo_server_get_socket_fd(broadcastServ);
  int sockopt = 1;
  lo_send_from(broadcastAddr, broadcastServ, LO_TT_IMMEDIATE, "/some/messages", "s", "test");

Thanks for everyone's collective input.

-Mike


 
Nicholas J Humfrey wrote:
> Can't you get the socket descriptor using lo_server_get_socket_fd and  
> set the SO_BROADCAST option yourself?
>
> Alternatively why not use liblo's multicast support? On your local  
> subnet multicast will behave very much like broadcast anyway...
>
>
> nick.
>
>
> On 25 Jan 2009, at 07:33, Mike Wozniewski wrote:
>
>   
>> True. But there is no way to set the broadcast flag for an  
>> lo_server. It
>> seems like the only way to set the broadcast flag on a socket is to  
>> use
>> regular lo_send() in a process that has not defined ANY lo_servers.  
>> This
>> seems pretty restrictive.
>>
>> Although, your comment makes me think of a 3rd possible solution to  
>> add
>> to my previous two:
>>
>> Why not create an lo_server_new_broadcast() method, and then we could
>> use the lo_send_from() function to solve my problem?
>>
>> Any thoughts on this?
>>
>> -Mike
>>
>>
>>
>> Steve Harris wrote:
>>     
>>> I'm not sure if this is relevant, but there's a lo_send_from() for
>>> dealing with the case where you have multiple servers.
>>>
>>> - Steve
>>>
>>> On 24 Jan 2009, at 00:50, Mike Wozniewski wrote:
>>>
>>>
>>>       
>>>> Hi Steve,
>>>>
>>>> I think I found the reason... and it seems to be an confusion with  
>>>> the
>>>> programming interface issue for liblo.
>>>>
>>>> I tried checking if the SO_BROADCAST flag was set just before the  
>>>> data
>>>> is sent in send_data() using getsockopt(), and it's NOT!
>>>>
>>>> This is because my data is actually being sent using a different
>>>> socket.
>>>> See this:
>>>>
>>>>   // Re-use existing socket?
>>>>   if (from) {
>>>>       sock = from->socket;
>>>>   } else if (a->protocol == LO_UDP && lo_client_sockets.udp!=-1) {
>>>>       sock = lo_client_sockets.udp;
>>>>   } else {
>>>>       if (a->socket==-1) {
>>>>           ret = create_socket( a );
>>>>           if (ret) return ret;
>>>>       }
>>>>       sock = a->socket;
>>>>   }
>>>>
>>>> What I didn't mention in my previous email was that I also have
>>>> another
>>>> liblo_server in the same process (used for something entirely
>>>> different).
>>>>
>>>> When I do:
>>>>
>>>>   lo_send(broadcastAddr, "/some/messages", "s", "test")
>>>>
>>>> It looks to see if there are any existing sockets, finds one in
>>>> lo_client_sockets, and uses that one. The create_socket() function  
>>>> is
>>>> never even called, which is the only place in the liblo source that
>>>> the
>>>> SO_BROADCAST flag can be set.
>>>>
>>>> Normally, this error would not happen. It's only because I have
>>>> another
>>>> socket available!
>>>>
>>>> I'm not sure how to solve this ....
>>>>
>>>> - Perhaps the check for broadcast should be moved into the  
>>>> send_data()
>>>> function. Although that would add extra work on each packet (not too
>>>> much though).
>>>> - The other solution would be to create a new socket for each new
>>>> address. It seems to me that the re-use of the lo_client_sockets.udp
>>>> socket is not necessary. Most applications will only send to a
>>>> couple of
>>>> addresses. It's reasonable to create a new socket for each  
>>>> address, as
>>>> long as you enable the SO_REUSEADDR flag. Don't you think?
>>>>
>>>> Also, the SO_BROADCAST flag should be set for both general and  
>>>> subnet
>>>> broadcast (ie, as long as ip[3]==255), otherwise it prevents users
>>>> like
>>>> me from doing subnet broadcasts.
>>>>
>>>> I'd love to hear your thoughts on my discovery.
>>>>
>>>> Thanks,
>>>> Mike
>>>>
>>>>
>>>>
>>>> Stephen Sinclair wrote:
>>>>
>>>>         
>>>>> On Thu, Jan 22, 2009 at 2:25 PM, Mike Wozniewski <mi...@mi...>
>>>>> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Hi all,
>>>>>>
>>>>>> I'm trying to use liblo for broadcast on a local LAN, and I can't
>>>>>> get it
>>>>>> to work.
>>>>>>
>>>>>> I'm using the lo_send() method to the address osc.udp://
>>>>>> 10.10.10.255:9090/
>>>>>>
>>>>>> Looking in the code, I see that liblo checks the address to see if
>>>>>> it's
>>>>>> 255.255.255.255, and sets the SO_BROADCAST socket option if that's
>>>>>> true.
>>>>>> First, this worries me because really, only the last .255 is
>>>>>> required.
>>>>>>
>>>>>>
>>>>>>             
>>>>> As far as I understand 255.255.255.255 is the broadcast address,  
>>>>> and
>>>>> 10.10.10.255 is the "subnet broadcast" address.  (Whose pattern
>>>>> depends on the netmask so I don't know how we could detect it, it
>>>>> would need an additional API call I think.  Though I suppose  
>>>>> chances
>>>>> are that if the last is 255 it's likely a broastcast, but I don't
>>>>> think it's strictly true.)
>>>>>
>>>>> They behave differently.  Normal broadcast messages are generally  
>>>>> not
>>>>> forwarded by the router, while subnet broadcasts sometimes are.   
>>>>> You
>>>>> might want to use wireshark and "netcat -u -l" to check whether  
>>>>> your
>>>>> messages are actually being sent and received, on the local  
>>>>> computer,
>>>>> and on the subnet.  Try with normal and subnet broadcast.
>>>>>
>>>>> As long as SO_BROADCAST is being set, it should behave like a  
>>>>> normal
>>>>> UDP packet.  If you can show it's really not working I'd be
>>>>> interested
>>>>> to know.  I see several reports on the net about people having
>>>>> trouble
>>>>> with subnet broadcast, so who knows.  You could also try multicast.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> So how do you enable broadcast?
>>>>>>
>>>>>> Not like this?:
>>>>>>
>>>>>>  string port = "9090"
>>>>>>  string addr = "10.10.10.255";
>>>>>>  broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
>>>>>>  lo_send(broadcastAddr, "/some/messages", "s", "test");
>>>>>>
>>>>>>
>>>>>>             
>>>>> well, as you said it only detects the full broadcast IP.  But if  
>>>>> you
>>>>> disabled that check then it should be setting the SO_BROADCAST  
>>>>> socket
>>>>> option.
>>>>>
>>>>>
>>>>> Steve
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by:
>>>>> SourcForge Community
>>>>> SourceForge wants to tell your story.
>>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>>> _______________________________________________
>>>>> liblo-devel mailing list
>>>>> lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by:
>>>> SourcForge Community
>>>> SourceForge wants to tell your story.
>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>
>>>>         
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>>       
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>     
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

Can't you get the socket descriptor using lo_server_get_socket_fd and  
set the SO_BROADCAST option yourself?

Alternatively why not use liblo's multicast support? On your local  
subnet multicast will behave very much like broadcast anyway...


nick.


On 25 Jan 2009, at 07:33, Mike Wozniewski wrote:

> True. But there is no way to set the broadcast flag for an  
> lo_server. It
> seems like the only way to set the broadcast flag on a socket is to  
> use
> regular lo_send() in a process that has not defined ANY lo_servers.  
> This
> seems pretty restrictive.
>
> Although, your comment makes me think of a 3rd possible solution to  
> add
> to my previous two:
>
> Why not create an lo_server_new_broadcast() method, and then we could
> use the lo_send_from() function to solve my problem?
>
> Any thoughts on this?
>
> -Mike
>
>
>
> Steve Harris wrote:
>> I'm not sure if this is relevant, but there's a lo_send_from() for
>> dealing with the case where you have multiple servers.
>>
>> - Steve
>>
>> On 24 Jan 2009, at 00:50, Mike Wozniewski wrote:
>>
>>
>>> Hi Steve,
>>>
>>> I think I found the reason... and it seems to be an confusion with  
>>> the
>>> programming interface issue for liblo.
>>>
>>> I tried checking if the SO_BROADCAST flag was set just before the  
>>> data
>>> is sent in send_data() using getsockopt(), and it's NOT!
>>>
>>> This is because my data is actually being sent using a different
>>> socket.
>>> See this:
>>>
>>>   // Re-use existing socket?
>>>   if (from) {
>>>       sock = from->socket;
>>>   } else if (a->protocol == LO_UDP && lo_client_sockets.udp!=-1) {
>>>       sock = lo_client_sockets.udp;
>>>   } else {
>>>       if (a->socket==-1) {
>>>           ret = create_socket( a );
>>>           if (ret) return ret;
>>>       }
>>>       sock = a->socket;
>>>   }
>>>
>>> What I didn't mention in my previous email was that I also have
>>> another
>>> liblo_server in the same process (used for something entirely
>>> different).
>>>
>>> When I do:
>>>
>>>   lo_send(broadcastAddr, "/some/messages", "s", "test")
>>>
>>> It looks to see if there are any existing sockets, finds one in
>>> lo_client_sockets, and uses that one. The create_socket() function  
>>> is
>>> never even called, which is the only place in the liblo source that
>>> the
>>> SO_BROADCAST flag can be set.
>>>
>>> Normally, this error would not happen. It's only because I have
>>> another
>>> socket available!
>>>
>>> I'm not sure how to solve this ....
>>>
>>> - Perhaps the check for broadcast should be moved into the  
>>> send_data()
>>> function. Although that would add extra work on each packet (not too
>>> much though).
>>> - The other solution would be to create a new socket for each new
>>> address. It seems to me that the re-use of the lo_client_sockets.udp
>>> socket is not necessary. Most applications will only send to a
>>> couple of
>>> addresses. It's reasonable to create a new socket for each  
>>> address, as
>>> long as you enable the SO_REUSEADDR flag. Don't you think?
>>>
>>> Also, the SO_BROADCAST flag should be set for both general and  
>>> subnet
>>> broadcast (ie, as long as ip[3]==255), otherwise it prevents users
>>> like
>>> me from doing subnet broadcasts.
>>>
>>> I'd love to hear your thoughts on my discovery.
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>> Stephen Sinclair wrote:
>>>
>>>> On Thu, Jan 22, 2009 at 2:25 PM, Mike Wozniewski <mi...@mi...>
>>>> wrote:
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm trying to use liblo for broadcast on a local LAN, and I can't
>>>>> get it
>>>>> to work.
>>>>>
>>>>> I'm using the lo_send() method to the address osc.udp://
>>>>> 10.10.10.255:9090/
>>>>>
>>>>> Looking in the code, I see that liblo checks the address to see if
>>>>> it's
>>>>> 255.255.255.255, and sets the SO_BROADCAST socket option if that's
>>>>> true.
>>>>> First, this worries me because really, only the last .255 is
>>>>> required.
>>>>>
>>>>>
>>>> As far as I understand 255.255.255.255 is the broadcast address,  
>>>> and
>>>> 10.10.10.255 is the "subnet broadcast" address.  (Whose pattern
>>>> depends on the netmask so I don't know how we could detect it, it
>>>> would need an additional API call I think.  Though I suppose  
>>>> chances
>>>> are that if the last is 255 it's likely a broastcast, but I don't
>>>> think it's strictly true.)
>>>>
>>>> They behave differently.  Normal broadcast messages are generally  
>>>> not
>>>> forwarded by the router, while subnet broadcasts sometimes are.   
>>>> You
>>>> might want to use wireshark and "netcat -u -l" to check whether  
>>>> your
>>>> messages are actually being sent and received, on the local  
>>>> computer,
>>>> and on the subnet.  Try with normal and subnet broadcast.
>>>>
>>>> As long as SO_BROADCAST is being set, it should behave like a  
>>>> normal
>>>> UDP packet.  If you can show it's really not working I'd be
>>>> interested
>>>> to know.  I see several reports on the net about people having
>>>> trouble
>>>> with subnet broadcast, so who knows.  You could also try multicast.
>>>>
>>>>
>>>>
>>>>
>>>>> So how do you enable broadcast?
>>>>>
>>>>> Not like this?:
>>>>>
>>>>>  string port = "9090"
>>>>>  string addr = "10.10.10.255";
>>>>>  broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
>>>>>  lo_send(broadcastAddr, "/some/messages", "s", "test");
>>>>>
>>>>>
>>>> well, as you said it only detects the full broadcast IP.  But if  
>>>> you
>>>> disabled that check then it should be setting the SO_BROADCAST  
>>>> socket
>>>> option.
>>>>
>>>>
>>>> Steve
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by:
>>>> SourcForge Community
>>>> SourceForge wants to tell your story.
>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

True. But there is no way to set the broadcast flag for an lo_server. It 
seems like the only way to set the broadcast flag on a socket is to use 
regular lo_send() in a process that has not defined ANY lo_servers. This 
seems pretty restrictive.

Although, your comment makes me think of a 3rd possible solution to add 
to my previous two:

Why not create an lo_server_new_broadcast() method, and then we could 
use the lo_send_from() function to solve my problem?

Any thoughts on this?

-Mike



Steve Harris wrote:
> I'm not sure if this is relevant, but there's a lo_send_from() for  
> dealing with the case where you have multiple servers.
>
> - Steve
>
> On 24 Jan 2009, at 00:50, Mike Wozniewski wrote:
>
>   
>> Hi Steve,
>>
>> I think I found the reason... and it seems to be an confusion with the
>> programming interface issue for liblo.
>>
>> I tried checking if the SO_BROADCAST flag was set just before the data
>> is sent in send_data() using getsockopt(), and it's NOT!
>>
>> This is because my data is actually being sent using a different  
>> socket.
>> See this:
>>
>>    // Re-use existing socket?
>>    if (from) {
>>        sock = from->socket;
>>    } else if (a->protocol == LO_UDP && lo_client_sockets.udp!=-1) {
>>        sock = lo_client_sockets.udp;
>>    } else {
>>        if (a->socket==-1) {
>>            ret = create_socket( a );
>>            if (ret) return ret;
>>        }
>>        sock = a->socket;
>>    }
>>
>> What I didn't mention in my previous email was that I also have  
>> another
>> liblo_server in the same process (used for something entirely  
>> different).
>>
>> When I do:
>>
>>    lo_send(broadcastAddr, "/some/messages", "s", "test")
>>
>> It looks to see if there are any existing sockets, finds one in
>> lo_client_sockets, and uses that one. The create_socket() function is
>> never even called, which is the only place in the liblo source that  
>> the
>> SO_BROADCAST flag can be set.
>>
>> Normally, this error would not happen. It's only because I have  
>> another
>> socket available!
>>
>> I'm not sure how to solve this ....
>>
>> - Perhaps the check for broadcast should be moved into the send_data()
>> function. Although that would add extra work on each packet (not too
>> much though).
>> - The other solution would be to create a new socket for each new
>> address. It seems to me that the re-use of the lo_client_sockets.udp
>> socket is not necessary. Most applications will only send to a  
>> couple of
>> addresses. It's reasonable to create a new socket for each address, as
>> long as you enable the SO_REUSEADDR flag. Don't you think?
>>
>> Also, the SO_BROADCAST flag should be set for both general and subnet
>> broadcast (ie, as long as ip[3]==255), otherwise it prevents users  
>> like
>> me from doing subnet broadcasts.
>>
>> I'd love to hear your thoughts on my discovery.
>>
>> Thanks,
>> Mike
>>
>>
>>
>> Stephen Sinclair wrote:
>>     
>>> On Thu, Jan 22, 2009 at 2:25 PM, Mike Wozniewski <mi...@mi...>  
>>> wrote:
>>>
>>>       
>>>> Hi all,
>>>>
>>>> I'm trying to use liblo for broadcast on a local LAN, and I can't  
>>>> get it
>>>> to work.
>>>>
>>>> I'm using the lo_send() method to the address osc.udp:// 
>>>> 10.10.10.255:9090/
>>>>
>>>> Looking in the code, I see that liblo checks the address to see if  
>>>> it's
>>>> 255.255.255.255, and sets the SO_BROADCAST socket option if that's  
>>>> true.
>>>> First, this worries me because really, only the last .255 is  
>>>> required.
>>>>
>>>>         
>>> As far as I understand 255.255.255.255 is the broadcast address, and
>>> 10.10.10.255 is the "subnet broadcast" address.  (Whose pattern
>>> depends on the netmask so I don't know how we could detect it, it
>>> would need an additional API call I think.  Though I suppose chances
>>> are that if the last is 255 it's likely a broastcast, but I don't
>>> think it's strictly true.)
>>>
>>> They behave differently.  Normal broadcast messages are generally not
>>> forwarded by the router, while subnet broadcasts sometimes are.  You
>>> might want to use wireshark and "netcat -u -l" to check whether your
>>> messages are actually being sent and received, on the local computer,
>>> and on the subnet.  Try with normal and subnet broadcast.
>>>
>>> As long as SO_BROADCAST is being set, it should behave like a normal
>>> UDP packet.  If you can show it's really not working I'd be  
>>> interested
>>> to know.  I see several reports on the net about people having  
>>> trouble
>>> with subnet broadcast, so who knows.  You could also try multicast.
>>>
>>>
>>>
>>>       
>>>> So how do you enable broadcast?
>>>>
>>>> Not like this?:
>>>>
>>>>   string port = "9090"
>>>>   string addr = "10.10.10.255";
>>>>   broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
>>>>   lo_send(broadcastAddr, "/some/messages", "s", "test");
>>>>
>>>>         
>>> well, as you said it only detects the full broadcast IP.  But if you
>>> disabled that check then it should be setting the SO_BROADCAST socket
>>> option.
>>>
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>>       
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>     
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

I'm not sure if this is relevant, but there's a lo_send_from() for  
dealing with the case where you have multiple servers.

- Steve

On 24 Jan 2009, at 00:50, Mike Wozniewski wrote:

> Hi Steve,
>
> I think I found the reason... and it seems to be an confusion with the
> programming interface issue for liblo.
>
> I tried checking if the SO_BROADCAST flag was set just before the data
> is sent in send_data() using getsockopt(), and it's NOT!
>
> This is because my data is actually being sent using a different  
> socket.
> See this:
>
>    // Re-use existing socket?
>    if (from) {
>        sock = from->socket;
>    } else if (a->protocol == LO_UDP && lo_client_sockets.udp!=-1) {
>        sock = lo_client_sockets.udp;
>    } else {
>        if (a->socket==-1) {
>            ret = create_socket( a );
>            if (ret) return ret;
>        }
>        sock = a->socket;
>    }
>
> What I didn't mention in my previous email was that I also have  
> another
> liblo_server in the same process (used for something entirely  
> different).
>
> When I do:
>
>    lo_send(broadcastAddr, "/some/messages", "s", "test")
>
> It looks to see if there are any existing sockets, finds one in
> lo_client_sockets, and uses that one. The create_socket() function is
> never even called, which is the only place in the liblo source that  
> the
> SO_BROADCAST flag can be set.
>
> Normally, this error would not happen. It's only because I have  
> another
> socket available!
>
> I'm not sure how to solve this ....
>
> - Perhaps the check for broadcast should be moved into the send_data()
> function. Although that would add extra work on each packet (not too
> much though).
> - The other solution would be to create a new socket for each new
> address. It seems to me that the re-use of the lo_client_sockets.udp
> socket is not necessary. Most applications will only send to a  
> couple of
> addresses. It's reasonable to create a new socket for each address, as
> long as you enable the SO_REUSEADDR flag. Don't you think?
>
> Also, the SO_BROADCAST flag should be set for both general and subnet
> broadcast (ie, as long as ip[3]==255), otherwise it prevents users  
> like
> me from doing subnet broadcasts.
>
> I'd love to hear your thoughts on my discovery.
>
> Thanks,
> Mike
>
>
>
> Stephen Sinclair wrote:
>> On Thu, Jan 22, 2009 at 2:25 PM, Mike Wozniewski <mi...@mi...>  
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to use liblo for broadcast on a local LAN, and I can't  
>>> get it
>>> to work.
>>>
>>> I'm using the lo_send() method to the address osc.udp:// 
>>> 10.10.10.255:9090/
>>>
>>> Looking in the code, I see that liblo checks the address to see if  
>>> it's
>>> 255.255.255.255, and sets the SO_BROADCAST socket option if that's  
>>> true.
>>> First, this worries me because really, only the last .255 is  
>>> required.
>>>
>>
>> As far as I understand 255.255.255.255 is the broadcast address, and
>> 10.10.10.255 is the "subnet broadcast" address.  (Whose pattern
>> depends on the netmask so I don't know how we could detect it, it
>> would need an additional API call I think.  Though I suppose chances
>> are that if the last is 255 it's likely a broastcast, but I don't
>> think it's strictly true.)
>>
>> They behave differently.  Normal broadcast messages are generally not
>> forwarded by the router, while subnet broadcasts sometimes are.  You
>> might want to use wireshark and "netcat -u -l" to check whether your
>> messages are actually being sent and received, on the local computer,
>> and on the subnet.  Try with normal and subnet broadcast.
>>
>> As long as SO_BROADCAST is being set, it should behave like a normal
>> UDP packet.  If you can show it's really not working I'd be  
>> interested
>> to know.  I see several reports on the net about people having  
>> trouble
>> with subnet broadcast, so who knows.  You could also try multicast.
>>
>>
>>
>>> So how do you enable broadcast?
>>>
>>> Not like this?:
>>>
>>>   string port = "9090"
>>>   string addr = "10.10.10.255";
>>>   broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
>>>   lo_send(broadcastAddr, "/some/messages", "s", "test");
>>>
>>
>> well, as you said it only detects the full broadcast IP.  But if you
>> disabled that check then it should be setting the SO_BROADCAST socket
>> option.
>>
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Steve,

I think I found the reason... and it seems to be an confusion with the 
programming interface issue for liblo.

I tried checking if the SO_BROADCAST flag was set just before the data 
is sent in send_data() using getsockopt(), and it's NOT!

This is because my data is actually being sent using a different socket. 
See this:

    // Re-use existing socket?
    if (from) {
        sock = from->socket;
    } else if (a->protocol == LO_UDP && lo_client_sockets.udp!=-1) {
        sock = lo_client_sockets.udp;
    } else {
        if (a->socket==-1) {
            ret = create_socket( a );
            if (ret) return ret;
        }
        sock = a->socket;
    }

What I didn't mention in my previous email was that I also have another 
liblo_server in the same process (used for something entirely different).

When I do:

    lo_send(broadcastAddr, "/some/messages", "s", "test")

It looks to see if there are any existing sockets, finds one in 
lo_client_sockets, and uses that one. The create_socket() function is 
never even called, which is the only place in the liblo source that the 
SO_BROADCAST flag can be set.

Normally, this error would not happen. It's only because I have another 
socket available!

I'm not sure how to solve this ....

- Perhaps the check for broadcast should be moved into the send_data() 
function. Although that would add extra work on each packet (not too 
much though).
- The other solution would be to create a new socket for each new 
address. It seems to me that the re-use of the lo_client_sockets.udp 
socket is not necessary. Most applications will only send to a couple of 
addresses. It's reasonable to create a new socket for each address, as 
long as you enable the SO_REUSEADDR flag. Don't you think?

Also, the SO_BROADCAST flag should be set for both general and subnet 
broadcast (ie, as long as ip[3]==255), otherwise it prevents users like 
me from doing subnet broadcasts.

I'd love to hear your thoughts on my discovery.

Thanks,
Mike



Stephen Sinclair wrote:
> On Thu, Jan 22, 2009 at 2:25 PM, Mike Wozniewski <mi...@mi...> wrote:
>   
>> Hi all,
>>
>> I'm trying to use liblo for broadcast on a local LAN, and I can't get it
>> to work.
>>
>> I'm using the lo_send() method to the address osc.udp://10.10.10.255:9090/
>>
>> Looking in the code, I see that liblo checks the address to see if it's
>> 255.255.255.255, and sets the SO_BROADCAST socket option if that's true.
>> First, this worries me because really, only the last .255 is required.
>>     
>
> As far as I understand 255.255.255.255 is the broadcast address, and
> 10.10.10.255 is the "subnet broadcast" address.  (Whose pattern
> depends on the netmask so I don't know how we could detect it, it
> would need an additional API call I think.  Though I suppose chances
> are that if the last is 255 it's likely a broastcast, but I don't
> think it's strictly true.)
>
> They behave differently.  Normal broadcast messages are generally not
> forwarded by the router, while subnet broadcasts sometimes are.  You
> might want to use wireshark and "netcat -u -l" to check whether your
> messages are actually being sent and received, on the local computer,
> and on the subnet.  Try with normal and subnet broadcast.
>
> As long as SO_BROADCAST is being set, it should behave like a normal
> UDP packet.  If you can show it's really not working I'd be interested
> to know.  I see several reports on the net about people having trouble
> with subnet broadcast, so who knows.  You could also try multicast.
>
>
>   
>> So how do you enable broadcast?
>>
>> Not like this?:
>>
>>    string port = "9090"
>>    string addr = "10.10.10.255";
>>    broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
>>    lo_send(broadcastAddr, "/some/messages", "s", "test");
>>     
>
> well, as you said it only detects the full broadcast IP.  But if you
> disabled that check then it should be setting the SO_BROADCAST socket
> option.
>
>
> Steve
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>   

On Thu, Jan 22, 2009 at 2:25 PM, Mike Wozniewski <mi...@mi...> wrote:
> Hi all,
>
> I'm trying to use liblo for broadcast on a local LAN, and I can't get it
> to work.
>
> I'm using the lo_send() method to the address osc.udp://10.10.10.255:9090/
>
> Looking in the code, I see that liblo checks the address to see if it's
> 255.255.255.255, and sets the SO_BROADCAST socket option if that's true.
> First, this worries me because really, only the last .255 is required.

As far as I understand 255.255.255.255 is the broadcast address, and
10.10.10.255 is the "subnet broadcast" address.  (Whose pattern
depends on the netmask so I don't know how we could detect it, it
would need an additional API call I think.  Though I suppose chances
are that if the last is 255 it's likely a broastcast, but I don't
think it's strictly true.)

They behave differently.  Normal broadcast messages are generally not
forwarded by the router, while subnet broadcasts sometimes are.  You
might want to use wireshark and "netcat -u -l" to check whether your
messages are actually being sent and received, on the local computer,
and on the subnet.  Try with normal and subnet broadcast.

As long as SO_BROADCAST is being set, it should behave like a normal
UDP packet.  If you can show it's really not working I'd be interested
to know.  I see several reports on the net about people having trouble
with subnet broadcast, so who knows.  You could also try multicast.


> So how do you enable broadcast?
>
> Not like this?:
>
>    string port = "9090"
>    string addr = "10.10.10.255";
>    broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
>    lo_send(broadcastAddr, "/some/messages", "s", "test");

well, as you said it only detects the full broadcast IP.  But if you
disabled that check then it should be setting the SO_BROADCAST socket
option.


Steve

Hi all,

I'm trying to use liblo for broadcast on a local LAN, and I can't get it 
to work.

I'm using the lo_send() method to the address osc.udp://10.10.10.255:9090/

Looking in the code, I see that liblo checks the address to see if it's 
255.255.255.255, and sets the SO_BROADCAST socket option if that's true. 
First, this worries me because really, only the last .255 is required.

ie, see the send_data() function in lo_send.c :

        // if UDP and destination address is broadcast allow broadcast on the
        // socket
        else if (a->protocol == LO_UDP && a->ai->ai_family == AF_INET)
    {
        // If UDP, and destination address is broadcast,
        // then allow broadcast on the socket.
        struct sockaddr_in* si = (struct sockaddr_in*)a->ai->ai_addr;
        unsigned char* ip = (unsigned char*)&(si->sin_addr);

        if (ip[0]==255 && ip[1]==255 && ip[2]==255 && ip[3]==255)
        {
            int opt = 1;
            setsockopt(a->socket, SOL_SOCKET, SO_BROADCAST, &opt, sizeof(int));
        }


However, even if I remove this conditional, is seems that broadcast 
still doesn't work. A print statement there actually never gets printed.

So how do you enable broadcast?

Not like this?:

    string port = "9090"
    string addr = "10.10.10.255";
    broadcastAddr = lo_address_new(addr.c_str(), port.c_str());
    lo_send(broadcastAddr, "/some/messages", "s", "test");


Thanks in advance for any help!
- Mike Wozniewski

Really nice !

On Wed, Jan 21, 2009 at 7:37 PM, Robert Carter
<r.c...@cs...>wrote:

> It's not pressure sensitive as far as I can tell.
>
> Rob
>
> On 21/01/2009, at 3:58 PM, Stephen Sinclair wrote:
>
> > Thanks for the links!  That's pretty great for only $40..!
> >
> > ( Found a price here:
> http://www.usbgeek.com/prod_detail.php?prod_id=0639
> >  )
> >
> > I couldn't tell from the description whether it is pressure-sensitive.
> > I would guess not, but still a nice deal. :)
> >
> > Steve
> >
> >
> > On Tue, Jan 20, 2009 at 9:45 PM, Robert Carter
> > <r.c...@cs...> wrote:
> >> Thanks for the responses.
> >>
> >> Here is a link to a picture of it:
> >>
> http://www.coolestgizmo.com/audio-gadgets/the-usb-drum-kit-for-music-nerds/
> >>
> >> I was attracted to it because it's flexible plastic, sealed against
> >> water and hard to break. You could use a lot of physical force and
> >> not
> >> harm the hardware - great for kids.
> >>
> >> Here are my notes so far:
> >>
> http://www.organicdesign.co.nz/USB_Roll-up_drum_kit_user-space_driver_for_linux
> >>
> >> Rob
> >>
> >> On 21/01/2009, at 3:37 PM, Stephen Sinclair wrote:
> >>
> >>> On Tue, Jan 20, 2009 at 8:40 PM, Julien 'Lta' BALLET
> >>> <elt...@gm...> wrote:
> >>>> Hi,
> >>>>
> >>>> On Wed, Jan 21, 2009 at 2:18 AM, Robert Carter <
> r.c...@cs...
> >>>>>
> >>>> wrote:
> >>>>>
> >>>>> Hi list,
> >>>>>
> >>>>> I'm writing a userspace driver for a USB device. I read the
> >>>>> example
> >>>>> code and liblo seems to be exactly what i'm looking for. My
> >>>>> question
> >>>>> is: Should I be writing a server or a client. I hope to be able to
> >>>>> connect my USB drum kit device to Chuck (the realtime music
> >>>>> language).
> >>>>> Chuck has the ability to receive OSC message and trigger sounds.
> >>>>> Does
> >>>>> this mean my software should be a client and Chuck should be the
> >>>>> server?
> >>>>
> >>>> IIRC, This is how it works :)
> >>>> Your application should be a client (ie send messages), and Chuck
> >>>> will
> >>>> receive them (be the server).
> >>>>
> >>>
> >>> That's correct.  Post a video when it's working!  ;-)  What analog
> >>> interface are you using out of curiosity?
> >>>
> >>>
> >>> Steve
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> This SF.net email is sponsored by:
> >>> SourcForge Community
> >>> SourceForge wants to tell your story.
> >>> http://p.sf.net/sfu/sf-spreadtheword
> >>> _______________________________________________
> >>> liblo-devel mailing list
> >>> lib...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by:
> >> SourcForge Community
> >> SourceForge wants to tell your story.
> >> http://p.sf.net/sfu/sf-spreadtheword
> >> _______________________________________________
> >> liblo-devel mailing list
> >> lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>



-- 
BALLET Julien
Owner of LabFree,  Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.b...@fr...> -- <elt...@gm...>
Web : http://freelab.epitech.eu

It's not pressure sensitive as far as I can tell.

Rob

On 21/01/2009, at 3:58 PM, Stephen Sinclair wrote:

> Thanks for the links!  That's pretty great for only $40..!
>
> ( Found a price here: http://www.usbgeek.com/prod_detail.php?prod_id=0639 
>  )
>
> I couldn't tell from the description whether it is pressure-sensitive.
> I would guess not, but still a nice deal. :)
>
> Steve
>
>
> On Tue, Jan 20, 2009 at 9:45 PM, Robert Carter
> <r.c...@cs...> wrote:
>> Thanks for the responses.
>>
>> Here is a link to a picture of it:
>> http://www.coolestgizmo.com/audio-gadgets/the-usb-drum-kit-for-music-nerds/
>>
>> I was attracted to it because it's flexible plastic, sealed against
>> water and hard to break. You could use a lot of physical force and  
>> not
>> harm the hardware - great for kids.
>>
>> Here are my notes so far:
>> http://www.organicdesign.co.nz/USB_Roll-up_drum_kit_user-space_driver_for_linux
>>
>> Rob
>>
>> On 21/01/2009, at 3:37 PM, Stephen Sinclair wrote:
>>
>>> On Tue, Jan 20, 2009 at 8:40 PM, Julien 'Lta' BALLET
>>> <elt...@gm...> wrote:
>>>> Hi,
>>>>
>>>> On Wed, Jan 21, 2009 at 2:18 AM, Robert Carter <r.c...@cs...
>>>>>
>>>> wrote:
>>>>>
>>>>> Hi list,
>>>>>
>>>>> I'm writing a userspace driver for a USB device. I read the  
>>>>> example
>>>>> code and liblo seems to be exactly what i'm looking for. My  
>>>>> question
>>>>> is: Should I be writing a server or a client. I hope to be able to
>>>>> connect my USB drum kit device to Chuck (the realtime music
>>>>> language).
>>>>> Chuck has the ability to receive OSC message and trigger sounds.
>>>>> Does
>>>>> this mean my software should be a client and Chuck should be the
>>>>> server?
>>>>
>>>> IIRC, This is how it works :)
>>>> Your application should be a client (ie send messages), and Chuck
>>>> will
>>>> receive them (be the server).
>>>>
>>>
>>> That's correct.  Post a video when it's working!  ;-)  What analog
>>> interface are you using out of curiosity?
>>>
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Thanks for the links!  That's pretty great for only $40..!

( Found a price here: http://www.usbgeek.com/prod_detail.php?prod_id=0639 )

I couldn't tell from the description whether it is pressure-sensitive.
 I would guess not, but still a nice deal. :)

Steve


On Tue, Jan 20, 2009 at 9:45 PM, Robert Carter
<r.c...@cs...> wrote:
> Thanks for the responses.
>
> Here is a link to a picture of it:
> http://www.coolestgizmo.com/audio-gadgets/the-usb-drum-kit-for-music-nerds/
>
> I was attracted to it because it's flexible plastic, sealed against
> water and hard to break. You could use a lot of physical force and not
> harm the hardware - great for kids.
>
> Here are my notes so far:
> http://www.organicdesign.co.nz/USB_Roll-up_drum_kit_user-space_driver_for_linux
>
> Rob
>
> On 21/01/2009, at 3:37 PM, Stephen Sinclair wrote:
>
>> On Tue, Jan 20, 2009 at 8:40 PM, Julien 'Lta' BALLET
>> <elt...@gm...> wrote:
>>> Hi,
>>>
>>> On Wed, Jan 21, 2009 at 2:18 AM, Robert Carter <r.c...@cs...
>>> >
>>> wrote:
>>>>
>>>> Hi list,
>>>>
>>>> I'm writing a userspace driver for a USB device. I read the example
>>>> code and liblo seems to be exactly what i'm looking for. My question
>>>> is: Should I be writing a server or a client. I hope to be able to
>>>> connect my USB drum kit device to Chuck (the realtime music
>>>> language).
>>>> Chuck has the ability to receive OSC message and trigger sounds.
>>>> Does
>>>> this mean my software should be a client and Chuck should be the
>>>> server?
>>>
>>> IIRC, This is how it works :)
>>> Your application should be a client (ie send messages), and Chuck
>>> will
>>> receive them (be the server).
>>>
>>
>> That's correct.  Post a video when it's working!  ;-)  What analog
>> interface are you using out of curiosity?
>>
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Thanks for the responses.

Here is a link to a picture of it:
http://www.coolestgizmo.com/audio-gadgets/the-usb-drum-kit-for-music-nerds/

I was attracted to it because it's flexible plastic, sealed against  
water and hard to break. You could use a lot of physical force and not  
harm the hardware - great for kids.

Here are my notes so far:
http://www.organicdesign.co.nz/USB_Roll-up_drum_kit_user-space_driver_for_linux

Rob

On 21/01/2009, at 3:37 PM, Stephen Sinclair wrote:

> On Tue, Jan 20, 2009 at 8:40 PM, Julien 'Lta' BALLET
> <elt...@gm...> wrote:
>> Hi,
>>
>> On Wed, Jan 21, 2009 at 2:18 AM, Robert Carter <r.c...@cs... 
>> >
>> wrote:
>>>
>>> Hi list,
>>>
>>> I'm writing a userspace driver for a USB device. I read the example
>>> code and liblo seems to be exactly what i'm looking for. My question
>>> is: Should I be writing a server or a client. I hope to be able to
>>> connect my USB drum kit device to Chuck (the realtime music  
>>> language).
>>> Chuck has the ability to receive OSC message and trigger sounds.  
>>> Does
>>> this mean my software should be a client and Chuck should be the  
>>> server?
>>
>> IIRC, This is how it works :)
>> Your application should be a client (ie send messages), and Chuck  
>> will
>> receive them (be the server).
>>
>
> That's correct.  Post a video when it's working!  ;-)  What analog
> interface are you using out of curiosity?
>
>
> Steve
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Tue, Jan 20, 2009 at 8:40 PM, Julien 'Lta' BALLET
<elt...@gm...> wrote:
> Hi,
>
> On Wed, Jan 21, 2009 at 2:18 AM, Robert Carter <r.c...@cs...>
> wrote:
>>
>> Hi list,
>>
>> I'm writing a userspace driver for a USB device. I read the example
>> code and liblo seems to be exactly what i'm looking for. My question
>> is: Should I be writing a server or a client. I hope to be able to
>> connect my USB drum kit device to Chuck (the realtime music language).
>> Chuck has the ability to receive OSC message and trigger sounds. Does
>> this mean my software should be a client and Chuck should be the server?
>
> IIRC, This is how it works :)
> Your application should be a client (ie send messages), and Chuck will
> receive them (be the server).
>

That's correct.  Post a video when it's working!  ;-)  What analog
interface are you using out of curiosity?


Steve

Hi,

On Wed, Jan 21, 2009 at 2:18 AM, Robert Carter
<r.c...@cs...>wrote:

> Hi list,
>
> I'm writing a userspace driver for a USB device. I read the example
> code and liblo seems to be exactly what i'm looking for. My question
> is: Should I be writing a server or a client. I hope to be able to
> connect my USB drum kit device to Chuck (the realtime music language).
> Chuck has the ability to receive OSC message and trigger sounds. Does
> this mean my software should be a client and Chuck should be the server?


IIRC, This is how it works :)
Your application should be a client (ie send messages), and Chuck will
receive them (be the server).

Julien.


>
>
> Rob
>
>
>
-- 
BALLET Julien
Owner of LabFree,  Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.b...@fr...> -- <elt...@gm...>
Web : http://freelab.epitech.eu

Hi list,

I'm writing a userspace driver for a USB device. I read the example  
code and liblo seems to be exactly what i'm looking for. My question  
is: Should I be writing a server or a client. I hope to be able to  
connect my USB drum kit device to Chuck (the realtime music language).  
Chuck has the ability to receive OSC message and trigger sounds. Does  
this mean my software should be a client and Chuck should be the server?

Rob

On 16 Jan 2009, at 04:34, Stephen Sinclair wrote:

> On Thu, Jan 15, 2009 at 11:21 PM, Stephen Sinclair <rad...@gm... 
> > wrote:
>> On Wed, Jan 14, 2009 at 4:30 AM, alex <al...@sl...> wrote:
>>> On Tue, 2009-01-13 at 18:21 -0500, Stephen Sinclair wrote:
>>>> I noticed that you're now returning the lo_timetag struct directly
>>>> instead of using a pointer.  I had to think twice about this as  
>>>> it's
>>>> not so usual to do, but it is supported by C and now that I think
>>>> about it, it is also how it is used in lo_message_add_timetag(), so
>>>> I'm okay with this.  If anyone has feelings on passing structs like
>>>> this in the API please say so.
>>>
>>> No particular feelings either way...
>>>
>>>> lo_message_get_timestamp -> lo_message_get_timetag
>>>>
>>>> To better match the rest of the API's lexicon.  (Always refers to
>>>> timestamps as "timetag".)
>>>
>>> I guess there's some logic to saying that a timestamp is a timetag  
>>> on a
>>> bundle, but yes keeping things consistent across the API is  
>>> clearly more
>>> important.
>>
>> Right, I see what you're saying. :)
>
> Though... now I'm doubting myself..
>
> I just realized while looking at it that we've got
> lo_send_timestamped() and lo_message_add_timetag().  Already a
> discrepancy.. and in that case, it seems "timestamp" refers to the
> message while "timetag" refers to an argument.  So maybe
> lo_message_get_timestamp() is a better name after all.

Yeah, that's because there is a difference.

Any old timetag in a message does not imply a timestamp, the timestamp  
slot in bundles is privileged.

- Steve

On Thu, Jan 15, 2009 at 11:21 PM, Stephen Sinclair <rad...@gm...> wrote:
> On Wed, Jan 14, 2009 at 4:30 AM, alex <al...@sl...> wrote:
>> On Tue, 2009-01-13 at 18:21 -0500, Stephen Sinclair wrote:
>>> I noticed that you're now returning the lo_timetag struct directly
>>> instead of using a pointer.  I had to think twice about this as it's
>>> not so usual to do, but it is supported by C and now that I think
>>> about it, it is also how it is used in lo_message_add_timetag(), so
>>> I'm okay with this.  If anyone has feelings on passing structs like
>>> this in the API please say so.
>>
>> No particular feelings either way...
>>
>>> lo_message_get_timestamp -> lo_message_get_timetag
>>>
>>> To better match the rest of the API's lexicon.  (Always refers to
>>> timestamps as "timetag".)
>>
>> I guess there's some logic to saying that a timestamp is a timetag on a
>> bundle, but yes keeping things consistent across the API is clearly more
>> important.
>
> Right, I see what you're saying. :)

Though... now I'm doubting myself..

I just realized while looking at it that we've got
lo_send_timestamped() and lo_message_add_timetag().  Already a
discrepancy.. and in that case, it seems "timestamp" refers to the
message while "timetag" refers to an argument.  So maybe
lo_message_get_timestamp() is a better name after all.

Hm...


Steve

On Wed, Jan 14, 2009 at 4:30 AM, alex <al...@sl...> wrote:
> On Tue, 2009-01-13 at 18:21 -0500, Stephen Sinclair wrote:
>> I noticed that you're now returning the lo_timetag struct directly
>> instead of using a pointer.  I had to think twice about this as it's
>> not so usual to do, but it is supported by C and now that I think
>> about it, it is also how it is used in lo_message_add_timetag(), so
>> I'm okay with this.  If anyone has feelings on passing structs like
>> this in the API please say so.
>
> No particular feelings either way...
>
>> lo_message_get_timestamp -> lo_message_get_timetag
>>
>> To better match the rest of the API's lexicon.  (Always refers to
>> timestamps as "timetag".)
>
> I guess there's some logic to saying that a timestamp is a timetag on a
> bundle, but yes keeping things consistent across the API is clearly more
> important.

Right, I see what you're saying. :)


Steve

On Tue, 2009-01-13 at 18:21 -0500, Stephen Sinclair wrote:
> I noticed that you're now returning the lo_timetag struct directly
> instead of using a pointer.  I had to think twice about this as it's
> not so usual to do, but it is supported by C and now that I think
> about it, it is also how it is used in lo_message_add_timetag(), so
> I'm okay with this.  If anyone has feelings on passing structs like
> this in the API please say so.

No particular feelings either way...

> lo_message_get_timestamp -> lo_message_get_timetag
> 
> To better match the rest of the API's lexicon.  (Always refers to
> timestamps as "timetag".)

I guess there's some logic to saying that a timestamp is a timetag on a
bundle, but yes keeping things consistent across the API is clearly more
important.

Cheers,

alex

-- 
http://yaxu.org/

On Mon, Jan 12, 2009 at 9:31 AM, alex <al...@sl...> wrote:
> On Sun, 2009-01-11 at 19:17 -0500, Stephen Sinclair wrote:
>> > Ok great!  Shall I kill the malloc() and send another patch?
>>
>> That would be great!
>
> Done -- attached.

Great!

I noticed that you're now returning the lo_timetag struct directly
instead of using a pointer.  I had to think twice about this as it's
not so usual to do, but it is supported by C and now that I think
about it, it is also how it is used in lo_message_add_timetag(), so
I'm okay with this.  If anyone has feelings on passing structs like
this in the API please say so.

One thing I'm probably going to change is:

lo_message_get_timestamp -> lo_message_get_timetag

To better match the rest of the API's lexicon.  (Always refers to
timestamps as "timetag".)

I hope it won't be confusing for users that get_timetag returns the
message's time at which it was sent, and add_timetag adds a timetag as
an argument.


Steve

On Mon, Jan 12, 2009 at 5:43 AM, Nicholas J Humfrey <nj...@ae...> wrote:
> I had a read through them and they all make sense. Not compiled/tested
> though.
>
> nick.
>
> --
> Sent from my phone.

Awesome, I always wondered if I'd be productive if I had some kind of
PDA that actually gave me a bash prompt and gcc.. ;-)

Thanks for the feedback.


Steve

On Sun, 2009-01-11 at 19:17 -0500, Stephen Sinclair wrote:
> I'm not sure what you mean by calculation time and audio time. Can you
> explain a bit?  I'm not very familiar with SuperCollider.

By calculation time I mean audio time minus some global latency.  A
global latency value is set to give everything enough time to calculate
samples before they need to be written out.

So say global latency l is set to 0.2 seconds, because in this system
nothing takes longer to calculate than that.  So I want to trigger a
sound at time t.  I timestamp a /trigger message with time t - l.  The
synth gets the message and queues it up until t - l.  Then when it's
released it adds l back on to the timestamp to find when exactly the
sound onset should be in the audio. 

Cheers

alex

On Sun, 2009-01-11 at 19:17 -0500, Stephen Sinclair wrote:
> > Ok great!  Shall I kill the malloc() and send another patch?
> 
> That would be great!

Done -- attached.

Cheres

alex