#1232 oscparse output un-routable for message address /volume/1

[Anonymous]

[oscparse] outputs the 1 of OSC message address /volume/1 as a symbol.
Therefore the message cannot be routed, as unlike [OSCroute] in 0.43-extended the forward slashes have been removed and replaced with white space.

0.46
OSX 10.8 Intel

[Anonymous]

Wouldn't the approach here be to just use [list tosymbol] ? Some one correct me?

[IOhannes m zmölnig]

i don't think so: [list tosymbol] will take a list of floats as ascii values and create a symbol from that. e.g. 64 becomes as symbol "@" (without the double-quotes).

in the original bug-report, we have a symbol "64" (without the double quotes) and want a number 64 instead.

[Anonymous]

oops, ya I meant [list fromsymbol] then you could route by ascii. That is somewhat indirect though.

[IOhannes m zmölnig]

i see. however, this get's complicated as soon as there "numeric symbols" exceed 9.

i think a better workaround is to route by "numeric symbols" instead:

|         [loadbang]
|         [1(
|         [makefilename %d]
|         |
[route foo]
|

[Anonymous]

Reading the OSC specs, address parts consist of string portions. So Pd is doing the right thing by outputting the address portions as symbols in the list.

The main problem is the inability for users to say "Hey, this is symbol 0, not number zero" (except with a workaround using [makefilename], but that will not work when routing with more than one possibility).

Something like [route "0" 0 "1" 1], where "0" is a symbol and 0 is a number.

I think, this would be a great addition to Pd, alongside the possibility to escape whitespace in symbols, but this could possibly break compatibility with older versions.

[IOhannes m zmölnig]

but how do you distinguish between the symbol 0 (written as "0") and the symbol "0"?

[Anonymous]

IMHO this is an addition in par with adding escape characters to symbol input, both in scope and in impact, and it should be done in the same version. Then with \" you can escape the quotation mark for symbols.

That would be a nice-to-have feature, but the discussion of escaping whitespace in Pd has been going on for a long time.