liblo-devel Mailing List for LibLO

Hi,

yes, that's the way liblo works. I guess what you'd need to do is
delegate the long work to a separate thread (while two_handler would do
nothing more than start that thread).

Cheers,
Martin

Am 11.06.15 um 22:40 schrieb Paul Keyes:
> Hi,
>
> I currently have a program with two osc message handlers:
>
> st.add_method("one", "iddddd", one_handler, NULL);
> st.add_method("two", "i", two_handler, NULL);
>
> I do a lot of stuff in two_handler that can take a minute or two. It
> seems like while two_handler is running, the messages for "one" are
> not received. Is this the way liblo works? And if so, is there a way
> around it?
>
> Cheers,
> Paul
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

I currently have a program with two osc message handlers:

st.add_method("one", "iddddd", one_handler, NULL);
st.add_method("two", "i", two_handler, NULL);

I do a lot of stuff in two_handler that can take a minute or two. It seems
like while two_handler is running, the messages for "one" are not received.
Is this the way liblo works? And if so, is there a way around it?

Cheers,
Paul

That's the function I was looking for!  ;)

Steve


On Thu, Jun 11, 2015 at 3:04 PM,  <to...@tr...> wrote:
>
> Hi,
> another way (maybe not the best) is
>
> unsigned char *data = lo_blob_dataptr((lo_blob)argv[i]);
>
> then to pick a float value
>
> float f1=*( (float*)(data + offset) );
>
> (where offset is a multiple of 4)
>
> Needs attention with big/little endian and blob size. Second part untested.
> Greetings
>
> On Thu, June 11, 2015 13:23, Stephen Sinclair wrote:
>> Good question.  If you look at the OSC spec, a blob is defined as a
>> 4-byte big-endian integer representing the size of the blob, followed
>> by the blob bytes, and some padding.  To get a pointer to the OSC argument
>> as "char", you can use the string pointer, ie. &argv[0]->s.
>>
>> So, to access your floats:
>>
>>
>> int blob_handler(const char *path, const char *types, lo_arg ** argv, int
>> argc, void *data, void *user_data) {
>> int *len = (int*)(&argv[0]->s); float *f = (float*)(&argv[0]->s +
>> sizeof(int)); printf("blob(%d): %f, %f, %f, %f\n", *l, f[0], f[1], f[2],
>> f[3]); return 0; }
>>
>>
>> I suppose it could be trivial to add the following to lo_arg,
>>
>>
>> /** Blob **/
>> struct { int32_t size; char data; } blob;
>>
>>
>> and then you'd be able to write,
>>
>> int len = argv[0]->blob.size; float *f = (float*)(&(argv[0]->blob.data));
>>
>> Anyways, hope that helps.
>>
>>
>> Steve
>>
>>
>> On Thu, Jun 11, 2015 at 4:12 AM, Paul Keyes <sps...@gm...> wrote:
>>
>>> Hi,
>>>
>>>
>>> I'm trying to send an array of floats as a blob.
>>>
>>>
>>> The sending side makes the blob like this:
>>>
>>>
>>> float s[4] = {1.7,2.7,3.7,4.7}; lo_blob btest = lo_blob_new(sizeof(s),
>>> s);
>>>
>>> ...then sends it like this:
>>>
>>>
>>> a.send("blob","b",btest);
>>>
>>> The receiving end does this:
>>>
>>>
>>> st.add_method("blob","b",blob_handler,NULL);
>>>
>>> ...but what do I put in this handler method to get the array of
>>> floats?:
>>>
>>>
>>> int blob_handler(const char *path, const char *types, lo_arg ** argv,
>>> int argc, void *data, void *user_data) {
>>> WHAT GOES HERE?
>>> return 0; }
>>>
>>>
>>> Any help is much appreciated!
>>>
>>>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,
another way (maybe not the best) is

unsigned char *data = lo_blob_dataptr((lo_blob)argv[i]);

then to pick a float value

float f1=*( (float*)(data + offset) );

(where offset is a multiple of 4)

Needs attention with big/little endian and blob size. Second part untested.
Greetings

On Thu, June 11, 2015 13:23, Stephen Sinclair wrote:
> Good question.  If you look at the OSC spec, a blob is defined as a
> 4-byte big-endian integer representing the size of the blob, followed
> by the blob bytes, and some padding.  To get a pointer to the OSC argument
> as "char", you can use the string pointer, ie. &argv[0]->s.
>
> So, to access your floats:
>
>
> int blob_handler(const char *path, const char *types, lo_arg ** argv, int
> argc, void *data, void *user_data) {
> int *len = (int*)(&argv[0]->s); float *f = (float*)(&argv[0]->s +
> sizeof(int)); printf("blob(%d): %f, %f, %f, %f\n", *l, f[0], f[1], f[2],
> f[3]); return 0; }
>
>
> I suppose it could be trivial to add the following to lo_arg,
>
>
> /** Blob **/
> struct { int32_t size; char data; } blob;
>
>
> and then you'd be able to write,
>
> int len = argv[0]->blob.size; float *f = (float*)(&(argv[0]->blob.data));
>
> Anyways, hope that helps.
>
>
> Steve
>
>
> On Thu, Jun 11, 2015 at 4:12 AM, Paul Keyes <sps...@gm...> wrote:
>
>> Hi,
>>
>>
>> I'm trying to send an array of floats as a blob.
>>
>>
>> The sending side makes the blob like this:
>>
>>
>> float s[4] = {1.7,2.7,3.7,4.7}; lo_blob btest = lo_blob_new(sizeof(s),
>> s);
>>
>> ...then sends it like this:
>>
>>
>> a.send("blob","b",btest);
>>
>> The receiving end does this:
>>
>>
>> st.add_method("blob","b",blob_handler,NULL);
>>
>> ...but what do I put in this handler method to get the array of
>> floats?:
>>
>>
>> int blob_handler(const char *path, const char *types, lo_arg ** argv,
>> int argc, void *data, void *user_data) {
>> WHAT GOES HERE?
>> return 0; }
>>
>>
>> Any help is much appreciated!
>>
>>

Right on!  That worked perfectly.

For others trying this, note that the line:
printf("blob(%d): %f, %f, %f, %f\n", *l, f[0], f[1], f[2], f[3]);

Should be:
printf("blob(%d): %f, %f, %f, %f\n", *len, f[0], f[1], f[2], f[3]);

On Thu, Jun 11, 2015 at 8:23 AM, Stephen Sinclair <rad...@gm...>
wrote:

> Good question.  If you look at the OSC spec, a blob is defined as a
> 4-byte big-endian integer representing the size of the blob, followed
> by the blob bytes, and some padding.  To get a pointer to the OSC
> argument as "char", you can use the string pointer, ie. &argv[0]->s.
>
> So, to access your floats:
>
> int blob_handler(const char *path, const char *types, lo_arg ** argv,
>                     int argc, void *data, void *user_data)
> {
>     int *len = (int*)(&argv[0]->s);
>     float *f = (float*)(&argv[0]->s + sizeof(int));
>     printf("blob(%d): %f, %f, %f, %f\n", *l, f[0], f[1], f[2], f[3]);
>     return 0;
> }
>
> I suppose it could be trivial to add the following to lo_arg,
>
>     /** Blob **/
>     struct {
>         int32_t size;
>         char data;
>     } blob;
>
> and then you'd be able to write,
>
>     int len = argv[0]->blob.size;
>     float *f = (float*)(&(argv[0]->blob.data));
>
> Anyways, hope that helps.
>
> Steve
>
> On Thu, Jun 11, 2015 at 4:12 AM, Paul Keyes <sps...@gm...> wrote:
> > Hi,
> >
> > I'm trying to send an array of floats as a blob.
> >
> > The sending side makes the blob like this:
> >
> >     float s[4] = {1.7,2.7,3.7,4.7};
> >     lo_blob btest = lo_blob_new(sizeof(s), s);
> >
> > ...then sends it like this:
> >
> >     a.send("blob","b",btest);
> >
> > The receiving end does this:
> >
> >     st.add_method("blob","b",blob_handler,NULL);
> >
> > ...but what do I put in this handler method to get the array of floats?:
> >
> >     int blob_handler(const char *path, const char *types, lo_arg ** argv,
> >                     int argc, void *data, void *user_data)
> >     {
> >        WHAT GOES HERE?
> >        return 0;
> >     }
> >
> > Any help is much appreciated!
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>

Good question.  If you look at the OSC spec, a blob is defined as a
4-byte big-endian integer representing the size of the blob, followed
by the blob bytes, and some padding.  To get a pointer to the OSC
argument as "char", you can use the string pointer, ie. &argv[0]->s.

So, to access your floats:

int blob_handler(const char *path, const char *types, lo_arg ** argv,
                    int argc, void *data, void *user_data)
{
    int *len = (int*)(&argv[0]->s);
    float *f = (float*)(&argv[0]->s + sizeof(int));
    printf("blob(%d): %f, %f, %f, %f\n", *l, f[0], f[1], f[2], f[3]);
    return 0;
}

I suppose it could be trivial to add the following to lo_arg,

    /** Blob **/
    struct {
        int32_t size;
        char data;
    } blob;

and then you'd be able to write,

    int len = argv[0]->blob.size;
    float *f = (float*)(&(argv[0]->blob.data));

Anyways, hope that helps.

Steve

On Thu, Jun 11, 2015 at 4:12 AM, Paul Keyes <sps...@gm...> wrote:
> Hi,
>
> I'm trying to send an array of floats as a blob.
>
> The sending side makes the blob like this:
>
>     float s[4] = {1.7,2.7,3.7,4.7};
>     lo_blob btest = lo_blob_new(sizeof(s), s);
>
> ...then sends it like this:
>
>     a.send("blob","b",btest);
>
> The receiving end does this:
>
>     st.add_method("blob","b",blob_handler,NULL);
>
> ...but what do I put in this handler method to get the array of floats?:
>
>     int blob_handler(const char *path, const char *types, lo_arg ** argv,
>                     int argc, void *data, void *user_data)
>     {
>        WHAT GOES HERE?
>        return 0;
>     }
>
> Any help is much appreciated!
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi,

I'm trying to send an array of floats as a blob.

The sending side makes the blob like this:

    float s[4] = {1.7,2.7,3.7,4.7};
    lo_blob btest = lo_blob_new(sizeof(s), s);

...then sends it like this:

    a.send("blob","b",btest);

The receiving end does this:

    st.add_method("blob","b",blob_handler,NULL);

...but what do I put in this handler method to get the array of floats?:

    int blob_handler(const char *path, const char *types, lo_arg ** argv,
                    int argc, void *data, void *user_data)
    {
       WHAT GOES HERE?
       return 0;
    }

Any help is much appreciated!

On 08/06/2015 12:59, Stephen Sinclair wrote:
> After running "premake4 vs2010" in the "build" directory, it should
> have generated a file called "config.h" in the main liblo directory.
> For me, this has the following values (liblo git master):
>
> #define LO_SO_VERSION {9, 0, 2}
> #define PACKAGE_VERSION "0.28"
>
> That said, I haven't compiled with MSVC in quite some time so YMMV.
>

Thanks Steve, it's all working for me now.

One last heads up...  when building with MSVC, the compiler complains 
because in the declaration of 'lo_message_add_varargs_internal()' 
(lo_lowlevel.h) parameter #5 is declared as "const int line".  But in 
the function body itself (message.c) it's defined as non-const.  Also, 
there's a second declaration for this function (send.c) where it's also 
declared as non-const.  They probably just need to be harmonized, one 
way or the other.  Best regards,

John

On Mon, Jun 8, 2015 at 11:39 AM, John Emmas <jo...@ti...> wrote:
> On 07/06/2015 17:39, Stephen Sinclair wrote:
>> On Sun, Jun 7, 2015 at 1:34 PM, John Emmas <jo...@ti...> wrote:
>>>
>>> I just downloaded the latest version from git.  I haven't tried building
>>> it yet but it does appear to be using closesocket() now. Thanks.
>> Indeed, it was fixed in the 0.27 release!  Thanks anyway for the feedback.
>>
>
> Thanks Steve,
>
> I attempted a build this morning (using MSVC) but I'm slightly confused
> about the function 'lo_version()'.  It uses what look like preprocessor
> directives called 'PACKAGE_VERSION' and 'LO_SO_VERSION' respectively.
> And it looks like I'd need to #define them in config-msvc.h.
>
> Can you give me an example of what those two symbols would look like in
> practice?  I'm not sure if they need to be strings or numeric values or
> one of each (in fact, LO_SO_VERSION looks like it might need to be an
> array of values).  Just a bit confused about it...

After running "premake4 vs2010" in the "build" directory, it should
have generated a file called "config.h" in the main liblo directory.
For me, this has the following values (liblo git master):

#define LO_SO_VERSION {9, 0, 2}
#define PACKAGE_VERSION "0.28"

That said, I haven't compiled with MSVC in quite some time so YMMV.

Steve

On 07/06/2015 17:39, Stephen Sinclair wrote:
> On Sun, Jun 7, 2015 at 1:34 PM, John Emmas <jo...@ti...> wrote:
>>
>> I just downloaded the latest version from git.  I haven't tried building
>> it yet but it does appear to be using closesocket() now. Thanks.
> Indeed, it was fixed in the 0.27 release!  Thanks anyway for the feedback.
>

Thanks Steve,

I attempted a build this morning (using MSVC) but I'm slightly confused 
about the function 'lo_version()'.  It uses what look like preprocessor 
directives called 'PACKAGE_VERSION' and 'LO_SO_VERSION' respectively.  
And it looks like I'd need to #define them in config-msvc.h.

Can you give me an example of what those two symbols would look like in 
practice?  I'm not sure if they need to be strings or numeric values or 
one of each (in fact, LO_SO_VERSION looks like it might need to be an 
array of values).  Just a bit confused about it...

John

On Sun, Jun 7, 2015 at 1:34 PM, John Emmas <jo...@ti...> wrote:
> On 07/06/2015 10:13, John Emmas wrote:
>> Just browsing through the code I've noticed that liblo uses 'socket()'.
>> In Windows, this gets implemented in WS2_32.dll.  Later (as necessary)
>> liblo closes the returned handle using 'close()'. Unfortunately, this
>> won't work in Windows because the returned handle isn't a conventional
>> file handle.  It needs to get closed using 'closesocket()'.
>>
>> I just wondered if this problem is already known about - or if it's
>> already fixed in the latest version?
>>
>
> I just downloaded the latest version from git.  I haven't tried building
> it yet but it does appear to be using closesocket() now. Thanks.

Indeed, it was fixed in the 0.27 release!  Thanks anyway for the feedback.

Steve

On 07/06/2015 10:13, John Emmas wrote:
> Just browsing through the code I've noticed that liblo uses 'socket()'.
> In Windows, this gets implemented in WS2_32.dll.  Later (as necessary)
> liblo closes the returned handle using 'close()'. Unfortunately, this
> won't work in Windows because the returned handle isn't a conventional
> file handle.  It needs to get closed using 'closesocket()'.
>
> I just wondered if this problem is already known about - or if it's
> already fixed in the latest version?
>

I just downloaded the latest version from git.  I haven't tried building 
it yet but it does appear to be using closesocket() now. Thanks.

John

Hi guys, this is my first post to this list (I think !) so apologies if 
this situation is already known about...

I'm one of the Windows developers for Harrison's "Mixbus" DAW.  It uses 
liblo and my current version is 0.26 (so slightly out of date now).

Just browsing through the code I've noticed that liblo uses 'socket()'.  
In Windows, this gets implemented in WS2_32.dll.  Later (as necessary) 
liblo closes the returned handle using 'close()'. Unfortunately, this 
won't work in Windows because the returned handle isn't a conventional 
file handle.  It needs to get closed using 'closesocket()'.

I just wondered if this problem is already known about - or if it's 
already fixed in the latest version?  Thanks.

John Emmas