liblo-devel Mailing List for LibLO

Indeed, well I see the utility of this... I'm surprised the only thing
you needed to change was passing an argument to getaddrinfo!  Very
clean, but the liblo API doesn't make it clean to add it.  I would be
more inclined perhaps to generalize it and add something that takes an
already-allocated server port or addrinfo or something along those
lines..

Also, a constructor for lo_server_thread taking a lo_server as
argument should be publicly available now that I think about it.

Possibly some kind of constructor taking a data structure with various
options could be a useful next step, although the downside is that
then there is a new data structure to maintain.  (Currently liblo's
API is function-based only.)

Still, I wonder if server initialization should be split into 2 stages
for the "low level" interface -- configuring server options, and then
opening the actual server.

Thinking wider, it's possibly time to start thinking about a liblo1
fork that breaks API/ABI compatibility.  There are several things I
would change.  Unfortunately I don't think I have enough time to
dedicate to it.

Steve




On Mon, Apr 4, 2016 at 6:19 AM, Erik Ronström <eri...@do...> wrote:
> Here’s a patch, should anyone else be interested!
>
> Usage:
>
> lo_server_thread st = lo_server_thread_new_with_proto_and_node(”777”, LO_TCP, ”127.0.0.1”, err_handler);
>
> Adding yet another constructor to server and server_thread is perhaps not very elegant – a nicer solution would be to add a node parameter to all of the constructor functions, however that would obviously break backward compability.
>
> Erik
>
>
>
>
>
>> 4 apr 2016 kl. 01:00 skrev Erik Ronström <eri...@do...>:
>>
>> Answering myself: it is not possible in the current implementation.
>>
>> The call to getaddrinfo in lo_server_new_with_proto_internal is hardcoded to use NULL as node and AI_PASSIVE for hints.ai_flags, which means that getaddrinfo will return wildcard addresses.
>>
>> Guess I’ll have to patch lo_server_new_with_proto_internal…
>>
>> Erik
>>
>>
>>> 3 apr 2016 kl. 10:20 skrev Erik Ronström <eri...@do...>:
>>>
>>> Hi,
>>>
>>> Is it possible to tell liblo to run a server only listening to
>>> localhost? I want to avoid the Windows Firewall popping up a warning
>>> when my audio server is started, and since I am only interested in
>>> connections from the same machine, it seems like it can be solved by
>>> binding the server to 127.0.0.1
>>> (http://stackoverflow.com/questions/3375435/avoid-windows-firewall-popup-with-sockets-on-localhost).
>>>
>>> Thanks
>>> Erik
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Here’s a patch, should anyone else be interested!

Usage:

lo_server_thread st = lo_server_thread_new_with_proto_and_node(”777”, LO_TCP, ”127.0.0.1”, err_handler);

Adding yet another constructor to server and server_thread is perhaps not very elegant – a nicer solution would be to add a node parameter to all of the constructor functions, however that would obviously break backward compability.

Erik

Answering myself: it is not possible in the current implementation.

The call to getaddrinfo in lo_server_new_with_proto_internal is hardcoded to use NULL as node and AI_PASSIVE for hints.ai_flags, which means that getaddrinfo will return wildcard addresses.

Guess I’ll have to patch lo_server_new_with_proto_internal…

Erik


> 3 apr 2016 kl. 10:20 skrev Erik Ronström <eri...@do...>:
> 
> Hi,
> 
> Is it possible to tell liblo to run a server only listening to 
> localhost? I want to avoid the Windows Firewall popping up a warning 
> when my audio server is started, and since I am only interested in 
> connections from the same machine, it seems like it can be solved by 
> binding the server to 127.0.0.1 
> (http://stackoverflow.com/questions/3375435/avoid-windows-firewall-popup-with-sockets-on-localhost).
> 
> Thanks
> Erik
> 
> 
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

Is it possible to tell liblo to run a server only listening to 
localhost? I want to avoid the Windows Firewall popping up a warning 
when my audio server is started, and since I am only interested in 
connections from the same machine, it seems like it can be solved by 
binding the server to 127.0.0.1 
(http://stackoverflow.com/questions/3375435/avoid-windows-firewall-popup-with-sockets-on-localhost).

Thanks
Erik

Great, perfect!


> 2 apr 2016 kl. 23:27 skrev Stephen Sinclair <rad...@gm...>:
> 
> On Fri, Apr 1, 2016 at 5:20 PM, Erik Ronström <er...@om...> wrote:
>> Allright!
>> 
>> Background: I use liblo together with portaudio to run an audio server, to which I can connect from my main application. To function correctly, portaudio needs to be initialized in the same thread as the audio stream is later started in. Since the audio stream is started from an OSC message handler, i.e. in the liblo server thread, the portaudio initialization must happen in that same thread. But that is not easily done, as there is no simple way to hook into the server thread. I could of course connect to the server from my main thread and call an init function, but that would not be very elegant.
>> 
>> Instead, I just added two callbacks to the server thread, one for initialization and one for cleanup. Attaching a patch below!
> 
> 
> I think this is a good idea, so I committed your work but also added
> some changes to the naming, hope you don't mind.
> 
> I preferred the word "callbacks" instead of "functions", for clarity.
> I also add some utility to the return value .. returning non-zero from
> the init function should abort starting the thread, allowing you to
> handle resource errors more nicely, I hope.
> 
> I also added a C++11 interface for the calls, so that lambdas can be used, etc.
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Fri, Apr 1, 2016 at 5:20 PM, Erik Ronström <er...@om...> wrote:
> Allright!
>
> Background: I use liblo together with portaudio to run an audio server, to which I can connect from my main application. To function correctly, portaudio needs to be initialized in the same thread as the audio stream is later started in. Since the audio stream is started from an OSC message handler, i.e. in the liblo server thread, the portaudio initialization must happen in that same thread. But that is not easily done, as there is no simple way to hook into the server thread. I could of course connect to the server from my main thread and call an init function, but that would not be very elegant.
>
> Instead, I just added two callbacks to the server thread, one for initialization and one for cleanup. Attaching a patch below!


I think this is a good idea, so I committed your work but also added
some changes to the naming, hope you don't mind.

I preferred the word "callbacks" instead of "functions", for clarity.
I also add some utility to the return value .. returning non-zero from
the init function should abort starting the thread, allowing you to
handle resource errors more nicely, I hope.

I also added a C++11 interface for the calls, so that lambdas can be used, etc.

Steve

Allright!

Background: I use liblo together with portaudio to run an audio server, to which I can connect from my main application. To function correctly, portaudio needs to be initialized in the same thread as the audio stream is later started in. Since the audio stream is started from an OSC message handler, i.e. in the liblo server thread, the portaudio initialization must happen in that same thread. But that is not easily done, as there is no simple way to hook into the server thread. I could of course connect to the server from my main thread and call an init function, but that would not be very elegant.

Instead, I just added two callbacks to the server thread, one for initialization and one for cleanup. Attaching a patch below!

Erik

Hi,

Great!
You can discuss it here, or make a PR/issue on Github or a ticket on
SourceForge.

Relevant links can be found on the web page:
http://liblo.sourceforge.net/

Steve


On Fri, Apr 1, 2016 at 12:50 PM, Erik Ronström
<eri...@do...> wrote:
> Hi List,
>
> I needed to patch liblo in order to use it in my application the way I wanted; and since the patch would possibly be of use to others, I wonder if there is an official way to publish it as a patch, or to propose it as a change to the main trunk.
>
> Regards
> Erik Ronström
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi List,

I needed to patch liblo in order to use it in my application the way I wanted; and since the patch would possibly be of use to others, I wonder if there is an official way to publish it as a patch, or to propose it as a change to the main trunk.

Regards
Erik Ronström