@alexandros Hello Alexandros........ I might boot into osx this evening (I recently installed vanilla there so as to try to understand the differences with extended)......
The integers in the message address do work in extended so maybe it will have to be referred as a vanilla bug. It is not "normal" to use the integer, but it is not excluded in the rules.............
Vanilla and extended in this patch......
osc_integer_message_address.pd
David.

A list of numbers does work with [route] in vanilla as well. It must a some kind of strange behavior with the vanilla OSC objects. I'm not sure.
In vanilla send a message "volume 1 1oo" to [route volume] and then to [route 1] and you'll get 100. Only in the patch I've recently posted with [oscparse] this didn't seem to work.

@alexandros Ok, I am 99.9% sure its a bug, but this is the first time I have ever opened vanilla. Because the "1" is part of the message address it has been interpreted as a symbol.......... (I think.. maybe... 99.9%)....... which is of course correct..... But then it cannot be routed,

[oscformat] creates the correct binary string,... but [oscparse] is bugged..............
[pack f f] complains and [pack s f] prints the integer (that needs to be a float to be routed) to a symbol box...........
vanilla_bug_oscparse.pd
Can a vanilla expert confirm?
If there is a way to circumvent the problem then of course it is not a bug....... but just an interesting problem to solve!!
I have reported it though......
David.

Ha!
Thanks for pointing this out! This issue was making me question things endlessly. Using Pd Vanilla 0.46.7 on macOS connected to TouchOSC. Using oscparse works well and route works as expected with symbols. But, in the Simple layout, TouchOSC begins most of its messages with page numbers so it was impossible for me to route them. Tried with another layout, which has sliders named without page numbers and it worked.
Phew!
Hope it’s been solved since then. (Thought my version was the latest and release notes since 0.46.7 don’t show anything about oscparse, but you never know.)

Tried in 0.47.1, same issue.
Really strange, though. And it’s possible to change some addresses of OSC messages but routing by number can be particularly useful.

@Enkerli Bug report still open.......... https://sourceforge.net/p/pure-data/bugs/1232/
IOhannes's solution should work for now...... routing by "numeric symbols".....

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

David.

@whale-av Hello David! Thanks for the reply. A bit confused about this, still.
So, here’s a message sent by TouchOSC:
list page4 multifader1 1 0.193394

My attempt at routing this…

         [oscparse]
|        [list trim]
|        [route page4]
|        [route multifader1]
|        [makefilename %d]
|        |
[route foo]

Getting the error:
makefilename: no method for '1'
Might have misunderstood the patching itself, though.
Here’s what it looks like in Pd.

@Enkerli "page4" and "multifader1" are spat out as symbols...... so no problem.
The problem is the "1" which is also a symbol. But [route 1] will only route the float "1" and rejects the symbol "1".
You can solve it like this (sorry, the diagram above is standard "how to post" but not very understandable at first).
Here you go.......... vanilla_bug_oscparse_solution.pd
[makefilename] replaces "symbolnumber" (which could be any symbol you like... foo .... bar .... woof... ) with a symbol...... in this case "1".

But...... it is probably easier to install the old Martin Peach OSC library from Pd Extended, using the Deken Plugin (Menu...Help... Find Externals)......
David.

@whale-av Thanks, David! Much easier to understand and it does work. Got the overall idea but not the actual patching.
Trying to focus on Vanilla without externals, in part to make it work on PdParty and/or MobMuPlat.
If it weren’t for that bug, oscparse would be fine for my needs (only UDP, not doing much with the messaging except getting the data into a slider).

Cheers!

--
Alex