[PD-dev] sendOSC bug - cannot send numeric symbols

Martin Peach martinrp at vax2.concordia.ca
Tue Mar 7 22:43:05 CET 2006


Claude Heiland-Allen wrote:

> Hi Frank, all,
>
> Frank Barknecht wrote:
>
>> Hallo,
>> Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
>
> >
>
>>> I'm trying to send the symbol output of [makefilename %d] using 
>>> sendOSC, but it gets sent as a number instead of as a string.  If I 
>>> use [makefilename x%d] it is sent as a string, but I don't want that 
>>> x there.  
>>
>>
>>
>> How are you sending? You cannot conserve "symbol 2" in a list- or
>> meta-message as in     [4(
>>   |
>>   [makefilename %d]
>>   |
>>   [send /test $1(
>>   |
>>   [sendOSC]
>>
>> as that would be sending the equivalent of [send /test 4( and your
>> "symbol" is gone before it reaches the [sendOSC]. You could of course
>> send: [send /test symbol 4( though you wouldn't need [makefilename] for
>> that (and it still wouldn't be a string for most apps...)
>
>
>
> I can quite imagine that $args in "messsagebox $1" get 
> 'reinterpreted', by which I mean converted to a string and then back 
> into whatever type Pd thinks that string should be (this is necessary 
> for constructs like "messagebox $1-blah".
>
> But, I'm using [pack s s s], and as the attached patch shows the real 
> type of each atom in the list is preserved as it should be, it's only 
> when it reaches sendOSC that the 'reinterpretation' occurs.
>
That's right. It's inside sendOSC that the arguments after "send" are 
converted to string and then parsed to determine the type for OSC. Any 
numeric characters become int unless they are adjacent to a '.' in which 
case they become float. Otherwise they are string. So there is no way to 
distinguish between '4' and '52'(the ASCII character '4') this way 
because 4 gets converted to 52 by atom_string and then reinterpreted as 
4 in ParseToken. You would have to [send four( instead.

In the function sendOSC_sendtyped in sendOSC.c we find:
  for (c=0;c<argc;c++) {
    atom_string(argv+c,tmp, MAXPDSTRING);

This part should really check the atom type and use atom_getfloat if 
it's a number, and then decide if it's an int or a float.
It also won't accept any other OSC types than string, float and int.
If I have time I'll try and fix it, if nobody else wants to...

Martin






More information about the Pd-dev mailing list