Hi, I'm using Vanilla 46-7

I'm parsing osc data from the "CONTROL (OSC+MIDI)" app.
When using the multitouchXT interface, I unpack the message using [unpack s f f].
The "s" is a number indicating which cursor is being moved or tapped, the two floats correspond to the X Y coordinates.
When I print the "s" directly, The console displays "symbol n" (n corresponds to the cursor number)
If I send the outlet corresponding to "s" to [$1( and print it afterwards, the console displays only the "n".

The problem I'm having, is that I can't find a way to use that "n" value to route or select different actions.

When using [select 1 2 3 4 5] feeding it from the [$1( I get a "no method for 'n' " message. But if I feed it directly from the unpack outlet it does not give back any error, but does not select anything either.

I guess I'm missing some very basic stuff, but I'm really stuck.

Thank you. Any advice would be greatly appreciated

PS: A completely different question: Today I've noticed several examples also inside the forum with text inside a number box.
Like: [text\ or two numbers separated by a space inside one box [1 22\ ... Is that possible? What is it supposed to mean?

@LiamG I will look at that this evening.......
Here is the patch that didn't work.....
vanilla_bug_oscparse.pd
From this thread..........
http://forum.pdpatchrepo.info/topic/9856/oscformat-and-oscparse-integer-not-routing-as-expected/3
If you have provided a workaround (or do in the future!) then it could be posted to the bug list as a solution.........
David.

@LiamG thank you so much. It does the trick for me.
Don't know how robust it is for other messages, but great work.
I'm afraid my expertise in PD is not enough to really understand what's going on in your patch, but I'll figure it out some day
Maybe in the meantime [s2l] or another different solution is implemented in Vanilla.

And thank you as well for answering regarding the 'Symbol atom' ... you're right. That's what I was seeing around. I never used it. Maybe now I'll do.

@Gaspar [list fromsymbol] converts the symbol to its ASCII code, which is essentially a list of numbers where every number corresponds to a character from the original symbol. In this code, "0" = 48, "1" = 49 ... and "9" = 57. This patch takes the ASCII number and subtracts 48 to get the original number. If there is more than one digits then the further characters are multiplied by a power of ten and added together. If the number is negative ("-" = 45) then it is multiplied by -1 at the end.

This won't work with decimal points yet--you'd have route 46 (code for " . ") from the list and then do something with the arithmetic.

Also, there is one number box in the patch just below the [- 48] object which I forgot to remove. You should delete it and connect around it.

[float] should be given a symbol method that tries to parse the incoming symbol to a float. If it can, forward the result to the float method. If it can't, error out as it currently does.

Downside: a patch author can not rely on [float] generating an error when it receives symbol atoms that can be parsed as floats. But it's a very edgy edge case where a patch author erroneously hooks up a symbol connection to [float], AND that symbol connection is only sending symbols that can be parsed as a float.

Actually, scratch that. It's not general enough-- for example, you still have zero control over creation arguments:

[keyname]
        |
        [select a q 1]

Here I really want to deal with symbol atoms, but that "1" in [select a q 1] is inescapably a float atom. For a new user, this means they must replace

problem -> obvious solution -> implementation

with

problem -> obvious solution -> implementation -> Pd idiosyncracy -> request for help -> lesson on Pd's type system -> replacing human-readable [keyname] API with character codes of [key] -> implementation

Edit: in Pd-l2ork that "1" is a float atom. In Pd Vanilla I believe that argument becomes a symbol atom set to empty symbol.

I think that the best solution would just be to put a symbol-to-list converter in Vanilla, perhaps in the [list] object itself. This is what I had guessed the new [list fromsymbol] function did before I tried it. Surely it would be more important than an ASCII code converter.

@LiamG Maybe it's best to just have a [list carwash] object that takes an incoming message, converts it to a list, converts the list to a string, and finally parses the string as a Pd message and outputs that.

So if we started with "symbol 1" where the "1" is a symbol atom:

1. "symbol 1" becomes "list 1" (where the "1" is still a symbol atom
2. "list 1" becomes the c string "list 1"
3. The c string "list 1" is parsed as a Pd message, which becomes "list 1" where "1" is now a float atom.

If you put a [list carwash] in between [keyname] and [select a q 1] above, it would do the "right thing". (Well, at least in Pd-l2ork it would.)

But there may be other gotchas here due to parser idiosyncracies I'm not considering...

@LiamG Thank you for the explanation. I'm familiar with ASCII, but actually at the first time I just had a quick glance at your [Vanilla_symbol_to_float] patch. Now, with your explanation, I've gone through it again and it is quite understandable.
Somehow and at least in lack of a better solution it seems elegant to me - Thank you again.

I was so grateful to find a solution to this that I ended up spending the rest of the evening rewriting the patch to accommodate a decimal point. maybe not very elegant, but here it is in case anyone else needs to stay in vanilla:

stof.pd

@LiamG said:

@whale-av said:

At the time I could see no way around it in 0.46-7.

Challenge accepted! I'm not saying that this is an elegant solution, but it will convert symbol-floats to real floats using only Vanilla objects. Things get confusing if you start feeding it regular symbols, though...

@matthewscharles But [float] does this already, doesn't it?

@ingox I wasn't aware -- I tried [makefilename %f] but didn't think to put the float in afterwards. help file says that mode is currently broken so I didn't investigate further.

thanks for pointing me to that! it was fun all the same.