edit: the message, even though it was sent as an int, was beeing received by pd as a symbol, using cyclone/fromsymbol before the number atom did the trick.

hi, im trying to receive an integer via OSC. if after unpackOSC and routeOSC y print the message, i get the number i'm sending, but as soon as i connect routeOSC to a number atom i get this message:

gatom: no method for '529'

can this be a bug in vanilla 0.50.2? i've done exactly the same before and it has worked...

@nzfs P.S.
It is not really a Vanilla "bug". The Osc spec is to send all parts of the message header....... the first part...... the "address"..... the part separated by /.../..../... as symbols.
But of course in Pd the [route] object is a symbol router if you put symbols as arguments...... or a float router if you put floats as arguments.
[route 1 2] will route float 1 and float 2...... but not symbol 1 and symbol 2.
So the routing fails.
David.

with [oscparse] you should also se [list trim] to trim out any identifier. Then you can send the output to [route] and use the OSC addresses as arguments to [route]. If though you have an address that goes deeper than one work, e.g. /my/osc/address then you'll probably need three cascaded [route] objects where each takes one of these words as an argument.

@alexandros i tried to do it the vanilla objects, after netreceive, oscparse and list trim i can print the message like this:

but if after that i try to route the message according to the address, it doesn't work.

EDIT: never mind the routing problem, i'm stupid enough to have misspelled 'wrist', but...
when i get to the end of the message and try to send the number to a number atom, i get the same problem as at the beginning (which i resolve with the fromsymbol object): gatom: no method for '255'

@nzfs Somehow this works: osc-test.pd. Probably the number is already encoded as a string by the sender.

@ingox yes, that might be the problem. im sending the message from the browser using nodejs and socketio, and even if the number is cast to an integer, i guess when it is send it's converted to a string.

@ingox without testing right now, I'd guess the difference is: OP says the message includes an integer type (i type tag). In Pd, the output from the number box is a float, not an integer, so I would guess it's formatting the number as a float. If so, then it's not a valid test.

I can try later with SuperCollider to Pd. (SC does encode integers as i).

hjh

@ddw_music i tried both as an integer and as a flot. so far the only workaround i found is using cyclone/fromsymbol and is working quite nice.

thank you all for the help

@nzfs TL;DR [oscparse] outputs integer arguments as numbers, not symbols. So, if you're getting a symbol, then it must be sent as a symbol -- so, check your nodejs code. It's probably applying an incorrect type tag.

My test:

This patch is a little simpler but it should still work with the multi-level command path:

And in SuperCollider, I wrote a quick function to hex-print the packet and send it. (The operative part for OSC transmission is n.sendMsg(*msg); -- the rest of the function is only for printing.)

(
n = NetAddr("127.0.0.1", 57119);

f = { |msg|
    // not necessary for sending -- just for printing
    var osc = msg.asRawOSC;
    osc.clump(32).do { |row|
        // hex
        row.do { |ch, i|
            "% ".postf(ch.asHexString(2));
            if(i % 8 == 7) { "  ".post };
        };
        // chars
        "    ".post;
        row.do { |ch, i|
            ch = ch.asAscii;
            if(ch.isPrint) { ch.post } { ".".post };
            if(i % 8 == 7) { " ".post };
        };
        "".postln;
    };
    n.sendMsg(*msg);
};
)

And, run it:

f.(['/test', 123]);  // integer
2F 74 65 73 74 00 00 00   2C 69 00 00 00 00 00 7B       /test... ,i.....{ 

f.(['/test', 123.0]);  // float
2F 74 65 73 74 00 00 00   2C 66 00 00 42 F6 00 00       /test... ,f..B... 

f.(['/test', '123']);  // symbol
2F 74 65 73 74 00 00 00   2C 73 00 00 31 32 33 00       /test... ,s..123. 

Note the 10th byte, the type tag for the argument: i, f or s.

For the integer, in Pd, I get "print: 123".

For the float, I get "print: 123".

For the symbol, I get "float: no method for '123'".

So... I'm 100% certain in the first case that it is being sent with an integer type tag, but that doesn't reproduce the problem. The only way I can reproduce the problem is by encoding the number as a symbol.

So my conclusion is that something is wrong on the sending side, not the receiving side.

hjh

@ddw_music yes, the problem must be in the sending side, i'm gonna check the code to see if i find where the problem is.
thank you for taking the time to do the test with sc

@nzfs Are x and y part of the message header i.e
/leftWrist/position/x 123
......In which case format as "i" as the x is part of the header and so a symbol

or sent as a symbol as part of the message i.e.
/leftWrist/position x 123
......In which case format as "si" as x is not part of the header and needs to be tagged.

As @ddw_music says an integer sent by [oscformat] will arrive as a float from [oscparse] as there is no integer type.
If you make x and y part of the header you negate the problem....... and that is where they should be anyway as they are part of the route.
David.

@whale-av i didn't had time to run more tests, but searching stackoverflow i found out that when you send a message using socket.io it's converted to a string, that's why it's all being received as a symbol in pd.