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 It could be that the previous vanilla bug (integers in the message header arriving as symbols) has been fixed.
Or..... that you have only just found the bug.
This folder test OSC.zip contains a test for vanilla...... for various message headers containing integers (and not).
There are objects with the same names as the MrPeach library (I built them to replace MrPeach in Vanilla) so to test you will need to keep them in the same folder so that they are found instead of the MrPeach objects.
It might give a clue as to what your problem is.......
I might have forgotten to include something so let me know if you get a "could not create" message.
If the test patch works then use my [routeOSC] object followed by a normal [route] ...... instead of the MrPeach [routeOSC]
You will have to put that object (and any other abstractions that it needs...... [s2l] etc.) from the zip above into your patch folder.
David.

Haven't tested David's patch, but it's clearly using the now native objects [oscparse] which is just what you need along with [netreceive -u -b] for receiveing OSC messages. No need for externals any more.

@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.