Hi all,
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. Without looking at the source for OSCx, it seems that sendOSC must be doing some conversion, which I don't want.
Any ideas? Is anyone familiar with the OSCx source and can fix this, sending all symbols as strings (and not sending symbols that look like numbers as numbers)?
Claude
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...)
Ciao
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.
Anyway, I rewrote the receiving program to accept numbers instead of strings, because I had that option, but this won't always be possible, so my conclusion is that sendOSC is broken.
Claude
#N canvas 210 109 569 503 10; #X obj 78 83 makefilename %d; #X floatatom 78 55 5 0 0 0 - - -; #X obj 13 111 pack s s s; #X obj 13 172 route list; #X msg 45 31 symbol blah; #X msg 13 9 symbol send; #X obj 13 133 t a a a; #X obj 133 202 unpack s s s; #X obj 131 228 unpack s s s; #X obj 35 231 route send; #X obj 13 196 t a a a; #X obj 38 274 route blah; #X obj 132 275 unpack s s; #X obj 130 296 unpack s; #X obj 38 252 t a a; #X obj 242 242 print p1; #X obj 238 265 print p2; #X obj 237 313 print p3; #X obj 235 342 print p4; #X obj 13 432 print out; #X obj 241 199 print in; #X text 135 370 ^^^ changing any of these [unpack ... s] to [unpack ... f] results in a type conversion error , so it is still a "real symbol" stored in a list at these points...; #X text 130 426 <<< this would be where [sendOSC] would be , which ignores the "real symbol" and sends it as a number instead.; #X connect 0 0 2 2; #X connect 1 0 0 0; #X connect 2 0 6 0; #X connect 3 0 10 0; #X connect 4 0 2 1; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 6 1 7 0; #X connect 6 2 20 0; #X connect 7 2 15 0; #X connect 8 2 16 0; #X connect 9 0 14 0; #X connect 10 0 19 0; #X connect 10 1 9 0; #X connect 10 2 8 0; #X connect 11 0 13 0; #X connect 12 1 17 0; #X connect 13 0 18 0; #X connect 14 0 11 0; #X connect 14 1 12 0;
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
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
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...
Oh, please do! ;)
Ciao
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
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.
Anyway, I rewrote the receiving program to accept numbers instead of strings, because I had that option, but this won't always be possible, so my conclusion is that sendOSC is broken.
Okay, I now checked the source code, and indeed, when typetags are on, numeric values are converted inside to be INT or FLOAT. The check is here:
typedArg ParseToken(char *token) { char *p = token; typedArg returnVal;
/* It might be an int, a float, or a string */
if (*p == '-') p++;
if (isdigit(*p) || *p == '.') { while (isdigit(*p)) p++; if (*p == '\0') { returnVal.type = INT_osc; returnVal.datum.i = atoi(token); return returnVal; } if (*p == '.') { p++; while (isdigit(*p)) p++; if (*p == '\0') { returnVal.type = FLOAT_osc; returnVal.datum.f = atof(token); return returnVal; } } }
returnVal.type = STRING_osc; returnVal.datum.s = token; return returnVal; }
Every element in the "send"-list will get passed through ParseToken(), and the isdigit()-checks will of course match the numeric values and set the types to INT_osc ("i") or FLOAT_osc ("f").
Well, I don't know what to do about this.
Ciao
-
Claude Heiland-Allen -
Frank Barknecht -
Martin Peach