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?

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