liblo-devel Mailing List for LibLO

> this might be obvious for you but: why can't you use OSC's arrays for this?
> if possible you should always avoid using blobs (== proprietary format)
> and use built-in types.

Arrays are mentioned in the OSC 1.0 spec, but at least to me, their definition seems very unclear (how is array length specified, for instance?). If you happen to know of some documentation of OSC arrays, please post a link here!

Regards
Erik

On 10/22/2015 04:47 PM, jpff wrote:
> The other problem I have is that there are 3 aggregate structures I
> need to send as a blob, tables, numeric arrays and string arrays, all
> which differ.

this might be obvious for you but: why can't you use OSC's arrays for this?
if possible you should always avoid using blobs (== proprietary format)
and use built-in types.

madsr
IOhannes

On Tue, Oct 27, 2015 at 3:30 PM, jpff <jp...@co...> wrote:
>
>
> On Tue, 27 Oct 2015, Stephen Sinclair wrote:
>
>> On Tue, Oct 27, 2015 at 3:07 PM, jpff <jp...@co...> wrote:
>>> Thank you for the responses and new example.  Amazingly I have
>>> transmission of csound arrays over OSC/liblo working.......except I
>>> followed the example of a .blob field and updated my liblo sources
>>> from git.  But the version of liblo distributed via packages etc does
>>> not have this.
>>>
>>> Questions:
>>> 1:  When might there be a new distribution?
>>
>> Not sure, perhaps we can do a release sometime soon, there have been
>> several commits since 0.28.  But, probably not for another couple of
>> months.
>
> That is way tooo late for me -- I am running a live system

I'm not sure I understand your constraints, but you are free to use
either the git version of the latest release.

>>> 2:  How can I change argv[i]->blob to something that runs under old
>>> library?
>>
>> Use lo_blob_dataptr() and lo_blob_datasize() as in the example.  The
>> .blob stuff was added recently, just for uniformity with other
>> argument types, but these functions have existed for a long time.
>
> I do not understand.  I am using those functions, but it is getting the
> argument to the is my problem.
>
> I currently have
> int len = lo_blob_datasize((lo_blob*)& argv[i]->blob)+sizeof(int);
> ...
> memcpy(m->args[i].blob, &argv[i]->blob, len);
>
> Can I really write
> (lo_blob*)& argv[i]
>
> Feels all wrong, and does not work either.

Did you look at example_server.c that I posted?  It says,

unsigned char *blobdata = lo_blob_dataptr((lo_blob)argv[0]);
int blobsize = lo_blob_datasize((lo_blob)argv[0]);

This works on my system.  (Ubuntu 14.04, x86_64)

I am not sure why you are adding sizeof(int) to the result of
lo_blob_datasize(). If you want to know the size of the blob including
the length field, you should use lo_blobsize().

Why does it "feel wrong"?  Basically when a message is received, it is
stored in a contiguous block of memory.  The argv array is a list of
pointers into this memory.  So, casting argv[i] to the appropriate
type for the type of the OSC argument makes sense.  lo_arg is just a
union making that easier, but it can just as easily be cast to a
lo_blob.  Lately I added a .blob member to lo_arg for consistency, but
a cast works just as well.

> Yes I need to copy the blob so it does not get freed too soon; took me
> time to figure that out

The memory is freed after the handler is called.  You can copy it with
memcpy, as you suggest.

Two other possibilities:

1) use lo_message_clone() to make a copy of the lo_message, and then
use lo_message_get_argv/c() to access the argument array later.
(Don't forget to free the memory allocated by lo_message_get_argv().)

2) use lo_message_incref() to tell liblo not to free the memory in the
handler's "data" argument. You should then be sure to use
lo_message_free() on that memory at a later time.

Method (1) was added in 0.27, and (2) was added in 0.28.


Hope that helps!

Steve

On Tue, 27 Oct 2015, Stephen Sinclair wrote:

> On Tue, Oct 27, 2015 at 3:07 PM, jpff <jp...@co...> wrote:
>> Thank you for the responses and new example.  Amazingly I have
>> transmission of csound arrays over OSC/liblo working.......except I
>> followed the example of a .blob field and updated my liblo sources
>> from git.  But the version of liblo distributed via packages etc does
>> not have this.
>>
>> Questions:
>> 1:  When might there be a new distribution?
>
> Not sure, perhaps we can do a release sometime soon, there have been
> several commits since 0.28.  But, probably not for another couple of
> months.

That is way tooo late for me -- I am running a live system


>
>> 2:  How can I change argv[i]->blob to something that runs under old
>> library?
>
> Use lo_blob_dataptr() and lo_blob_datasize() as in the example.  The
> .blob stuff was added recently, just for uniformity with other
> argument types, but these functions have existed for a long time.

I do not understand.  I am using those functions, but it is getting the 
argument to the is my problem.

I currently have
int len = lo_blob_datasize((lo_blob*)& argv[i]->blob)+sizeof(int);
...
memcpy(m->args[i].blob, &argv[i]->blob, len);

Can I really write
(lo_blob*)& argv[i]

Feels all wrong, and does not work either.

Yes I need to copy the blob so it does not get freed too soon; took me 
time to figure that out

==John ff

On Tue, Oct 27, 2015 at 3:07 PM, jpff <jp...@co...> wrote:
> Thank you for the responses and new example.  Amazingly I have
> transmission of csound arrays over OSC/liblo working.......except I
> followed the example of a .blob field and updated my liblo sources
> from git.  But the version of liblo distributed via packages etc does
> not have this.
>
> Questions:
> 1:  When might there be a new distribution?

Not sure, perhaps we can do a release sometime soon, there have been
several commits since 0.28.  But, probably not for another couple of
months.

> 2:  How can I change argv[i]->blob to something that runs under old
> library?

Use lo_blob_dataptr() and lo_blob_datasize() as in the example.  The
.blob stuff was added recently, just for uniformity with other
argument types, but these functions have existed for a long time.

Steve

Thank you for the responses and new example.  Amazingly I have
transmission of csound arrays over OSC/liblo working.......except I
followed the example of a .blob field and updated my liblo sources
from git.  But the version of liblo distributed via packages etc does
not have this.

Questions:
1:  When might there be a new distribution?

2:  How can I change argv[i]->blob to something that runs under old
library?

==John ffitch

On Thu, Oct 22, 2015 at 9:34 PM,  <to...@tr...> wrote:
> Hi,
> just a short addition, the src/testlo.c also shows many ways of how liblo
> can be used (including blobs).
> Greetings

Definitely, but it's almost certainly not good to rely on tests for
examples of how to use the library.  It's a bit of a mess, and there
are things in there testing the library internals.  In fact testlo
could use some serious cleaning up.  Most of it is one big function.

That said, yes, it has some cases that are not covered by the examples.

Steve

On Thu, October 22, 2015 18:05, Stephen Sinclair wrote:
> On Thu, Oct 22, 2015 at 4:47 PM, jpff <jp...@co...> wrote:
>
>> I suspect this is easy but I cannot get my head round it!  I am
>> looking at extending the OSC capabilities of csound, in particular to
>> send and receive tables and arrays.  I have code for the sending which
>> constructs a blob from the internal data structure and it seems to get
>> sent OK.  My problems are in receiving.  It get read and I can see
>> there is a blob but I cannot find the data.  Numbers are strings work
>> but when I attempt to read the blob in th handler it is null.  I looked
>> at the mail re an array of floats but that did not seem to help.
>>
>> The other problem I have is that there are 3 aggregate structures I
>> need to send as a blob, tables, numeric arrays and string arrays, all
>> which differ.  What I have doe so far is to steal 3 unallocated types
>> (GAS actually) i the data description.  Works well for send but I am
>> not sure this is the "correct" way, and until I can find the blob I
>> cannot test the receiver.
>>
>> Code in C by the way and in the csound format of opcodes.
>>
>>
>
> This was discussed fairly recently, so it's clear the docs need
> improvement.  I've added a handler to example_server showing how to access
> blob data:
>
> https://github.com/radarsat1/liblo/blob/master/examples/example_server.c
>
>
> (see function "blobtest_handler")
>
>
> More generally, example code and docs need improvement all around.
> The doxygen documentation is probably not enough, I get the impression
> we need examples showing how to accomplish specific tasks.  Personally I
> probably won't have much time for this in the near future, but it would be
> a great contribution if anyone is interested.  Especially since things
> seem to be pretty static regarding liblo lately.
>
> We could start by listing scenarios that might need examples.
>
>
> Steve
>
>
Hi,
just a short addition, the src/testlo.c also shows many ways of how liblo
can be used (including blobs).
Greetings

On 10/22/2015 9:05 AM, Stephen Sinclair wrote:

> More generally, example code and docs need improvement all around.
> The doxygen documentation is probably not enough, I get the impression
> we need examples showing how to accomplish specific tasks.

I've been on an API docs project for my job... it quickly became clear that 
the in-code doc is just not enough to start using the API; you need 
discussion of the organization, workflows, parameters & values, etc. Only 
then does the in-code doc become meaningful. Fortunately, there is some doc 
for the OSC protocol, we just need for for liblo. I'll say that the examples 
are good, although they might benefit from some more comments.

I don't have the time (or experience with it) either but would send an 
example to include if requested (needs cleanup first, though).

z!

On Thu, Oct 22, 2015 at 4:47 PM, jpff <jp...@co...> wrote:
> I suspect this is easy but I cannot get my head round it!  I am
> looking at extending the OSC capabilities of csound, in particular to
> send and receive tables and arrays.  I have code for the sending which
> constructs a blob from the internal data structure and it seems to get
> sent OK.  My problems are in receiving.  It get read and I can see there
> is a blob but I cannot find the data.  Numbers are strings work but
> when I attempt to read the blob in th handler it is null.  I looked at
> the mail re an array of floats but that did not seem to help.
>
> The other problem I have is that there are 3 aggregate structures I
> need to send as a blob, tables, numeric arrays and string arrays, all
> which differ.  What I have doe so far is to steal 3 unallocated types
> (GAS actually) i the data description.  Works well for send but I am
> not sure this is the "correct" way, and until I can find the blob I
> cannot test the receiver.
>
> Code in C by the way and in the csound format of opcodes.
>

This was discussed fairly recently, so it's clear the docs need
improvement.  I've added a handler to example_server showing how to
access blob data:

https://github.com/radarsat1/liblo/blob/master/examples/example_server.c

(see function "blobtest_handler")

More generally, example code and docs need improvement all around.
The doxygen documentation is probably not enough, I get the impression
we need examples showing how to accomplish specific tasks.  Personally
I probably won't have much time for this in the near future, but it
would be a great contribution if anyone is interested.  Especially
since things seem to be pretty static regarding liblo lately.

We could start by listing scenarios that might need examples.

Steve

I suspect this is easy but I cannot get my head round it!  I am
looking at extending the OSC capabilities of csound, in particular to
send and receive tables and arrays.  I have code for the sending which
constructs a blob from the internal data structure and it seems to get
sent OK.  My problems are in receiving.  It get read and I can see there
is a blob but I cannot find the data.  Numbers are strings work but
when I attempt to read the blob in th handler it is null.  I looked at
the mail re an array of floats but that did not seem to help.

The other problem I have is that there are 3 aggregate structures I
need to send as a blob, tables, numeric arrays and string arrays, all
which differ.  What I have doe so far is to steal 3 unallocated types
(GAS actually) i the data description.  Works well for send but I am
not sure this is the "correct" way, and until I can find the blob I
cannot test the receiver.

Code in C by the way and in the csound format of opcodes.

==John ffitch