liblo-devel Mailing List for LibLO

Hi,

While firing a lot of messages about with a perl script I have been testing, I noticed that after a while my server process could no longer send out messages.

I tracked the problem down to a socket leak. After replying to a message a server has recieved, liblo was not closing the socket. 

I have also optimised the sending code a bit, so that it does not create a socket at all, if it is not needed (useful for the new send_from calls).

Code is now in CVS.


nick.

Hi,

I have just released a new version of my perl bindings to LibLO.
It requires the CVS version of LibLO because it uses my new  
lo_send_message_from functions.

The main thing I changed in this release, is that every object is  
both a client and server. This makes replying to messages a lot easier.

Available from CPAN:
http://search.cpan.org/~njh/Net-LibLO/


nick.

Incase anyone is wondering, these are needed when you have multiple
servers, and want to send the message from a specific one, by default it
takes the most recently ccreated one.

- Steve

On Mon, Dec 05, 2005 at 10:54:06 +0000, Nicholas J Humfrey wrote:
> Hi,
> 
> I have just updated CVS and added four new functions.
> 
> lo_send_from(lo_address, lo_server, lo_timetag, path, type, ...)
> lo_send_message_from(lo_address, lo_server, lo_message )
> lo_send_bundle_from( lo_address, lo_server, lo_bundle)
> lo_server_thread_get_server( lo_server_thread )
> 
> The purpose of the functions is to allow an application with multiple  
> lo_servers to choose which socket a message is sent from.
> 
> lo_send_from accepts an optional timetag argument, so it can also be  
> used like lo_send_timestamped().
> 
> In small compensation for bulking up the liblo API, I have merged the  
> duplicated code in lo_send_message and lo_send_bundle_from into a new  
> static function called send_data.
> 
> 
> Unfortunately there is quite a lot of duplicated code in  
> lo_send_internal, lo_send_from_internal and  
> lo_send_timestamped_internal. Sadly these cannot be merged into a  
> single function, as it would break binary compatibility. The other  
> two of the functions cannot call lo_send_from_internal, because of  
> the complications of variable numbers of arguments.
> 
> 
> I have also bumped up the version number of liblo in CVS, in  
> preparation for the next release.
> 
> 
> Hope I haven't broken anything !
> 
> nick.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

I have just updated CVS and added four new functions.

lo_send_from(lo_address, lo_server, lo_timetag, path, type, ...)
lo_send_message_from(lo_address, lo_server, lo_message )
lo_send_bundle_from( lo_address, lo_server, lo_bundle)
lo_server_thread_get_server( lo_server_thread )

The purpose of the functions is to allow an application with multiple  
lo_servers to choose which socket a message is sent from.

lo_send_from accepts an optional timetag argument, so it can also be  
used like lo_send_timestamped().

In small compensation for bulking up the liblo API, I have merged the  
duplicated code in lo_send_message and lo_send_bundle_from into a new  
static function called send_data.


Unfortunately there is quite a lot of duplicated code in  
lo_send_internal, lo_send_from_internal and  
lo_send_timestamped_internal. Sadly these cannot be merged into a  
single function, as it would break binary compatibility. The other  
two of the functions cannot call lo_send_from_internal, because of  
the complications of variable numbers of arguments.


I have also bumped up the version number of liblo in CVS, in  
preparation for the next release.


Hope I haven't broken anything !

nick.

MadJACK is a MPEG Audio Deck for the Jack Audio Connection Kit with  
an OSC based control interface. It was written as a backend for DJ  
music playback and is released under the GPL licence.

http://www.ecs.soton.ac.uk/~njh/madjack/


It aims to achieve the following:
- Lightweight
- Talk natively to JACK
- Easy to script / remote control
- High Quality audio
- Skip free playback
- Responsive / Low Latency
- Reliable / Not Crash

It does not do the following:
- Decode metadata/ID3 tags
- Queue up multiple tracks
- Have playlists


Hope somebody else finds it as useful as I do!

nick.

I dont understand. OSX uses libtool library versioning doesnt it? The verson
of the library has nothing to do with the version of the package. I dont
quite remeber the deal, but if another 0.r.a library version comes out
isn't it binary compatible with other 0.r.as?

If you put the revision number first then there might be another 0.r.a in
the future if binary compatibility is broken. That doesnt make any sense to
me. c.f.
http://asis.web.cern.ch/asis/products/GNU.DVP/libtool-1.3.2/libtool_6.html

- Steve

On Sat, Dec 03, 2005 at 10:12:17 +0000, Nicholas J Humfrey wrote:
> Hi,
> 
> I was just trying to get liblo packaged up into fink, but have cope  
> up to a problem with library versioning on Darwin:
> 
> https://sourceforge.net/tracker/? 
> func=detail&atid=414256&aid=1372496&group_id=17203
> 
> 
> >The dylib names could be a problem. Rather than liblo.0.5.0.dylib  
> >and liblo.
> >0.dylib, they should be liblo.5.0.0.dylib and liblo.5.dylib. This  
> >is an upstream
> >mistake in versioning, but it means that if a version 6 comes out,  
> >it would also
> >have a liblo.0.dylib and would conflict. Meaning the new and old  
> >packages
> >couldn't be installed at the same time. Note that just renaming the  
> >file won't do
> >since the install_name of the library is "/sw/lib/liblo.0.dylib"  
> >and would also
> >have to be changed.
> 
> 
> I get really confused by library versioning.... but must be something  
> to do with LO_SO_VERSION ?
> 
> 
> nick.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

I was just trying to get liblo packaged up into fink, but have cope  
up to a problem with library versioning on Darwin:

https://sourceforge.net/tracker/? 
func=detail&atid=414256&aid=1372496&group_id=17203


> The dylib names could be a problem. Rather than liblo.0.5.0.dylib  
> and liblo.
> 0.dylib, they should be liblo.5.0.0.dylib and liblo.5.dylib. This  
> is an upstream
> mistake in versioning, but it means that if a version 6 comes out,  
> it would also
> have a liblo.0.dylib and would conflict. Meaning the new and old  
> packages
> couldn't be installed at the same time. Note that just renaming the  
> file won't do
> since the install_name of the library is "/sw/lib/liblo.0.dylib"  
> and would also
> have to be changed.


I get really confused by library versioning.... but must be something  
to do with LO_SO_VERSION ?


nick.